X-Recipient: archive-cygwin AT delorie DOT com DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:subject:to:references:from:message-id:date :mime-version:in-reply-to:content-type; q=dns; s=default; b=v9n1 p5FHWyDMMQyIh6uKkR5Ux6kzItqIWnHSBqnt78YGciHamnFTb14IX7wH4J8/oQxR oePdxqVeoYnESWcUdtMgx/pSpQn/NE0TSiEMAWVyMe0WknHp+mIfYpqarirXnnUg 5Sa972XP5SnjYObzORmgywPFIIYRrT0xzXz7PIE= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:subject:to:references:from:message-id:date :mime-version:in-reply-to:content-type; s=default; bh=M9ARHOB+e5 ul7XmnaUBJeCJMT6M=; b=uyaDkfGJA/resl0faNbEIWGwDmUWCzftlQwwyX3RWz x8EJHPHuKyemhv8PGFFNAqylug1zeS0H2jBtBnW6AB70DABR9oqsNGf516JLG/2h ULdmFrwXBLolBO1OsIg6QLjtJNNPpJ4p25KipqC0ctTZIr6dWF2mvWmnAgPrwr0y A= Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.1 spammy=balanced, layers X-HELO: mx1.redhat.com Subject: Re: Command line processing in dcrt0.cc does not match Microsoft parsing rules To: cygwin AT cygwin DOT com References: From: Eric Blake Openpgp: preference=signencrypt Message-ID: <68adcf5e-1e6a-67db-a028-e8953063fbd4@redhat.com> Date: Thu, 5 Sep 2019 17:46:28 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="YAZKN5rIgFnR3svaWeAn1iDu4DdWT33qr" X-IsSubscribed: yes --YAZKN5rIgFnR3svaWeAn1iDu4DdWT33qr Content-Type: multipart/mixed; boundary="7hicqN08iJUshQ2ENEkwo3wI01RIjsM7i"; protected-headers="v1" From: Eric Blake To: cygwin AT cygwin DOT com Message-ID: <68adcf5e-1e6a-67db-a028-e8953063fbd4 AT redhat DOT com> Subject: Re: Command line processing in dcrt0.cc does not match Microsoft parsing rules References: In-Reply-To: --7hicqN08iJUshQ2ENEkwo3wI01RIjsM7i Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 9/5/19 5:01 PM, Stephen Provine via cygwin wrote: > On 9/5/19 2:05 PM, Eric Blake wrote: >> On 9/5/19 1:31 PM, Stephen Provine via cygwin wrote: >>> Not expected. >=20 >> Why not? That obeyed cmd's odd rules: The moment you have a " in the >> command line, that argument continues until end of line or the next " >> (regardless of how many \ precede the "). >=20 > Now I'm really confused. Brian seemed to indicate that the POSIX rules we= re > followed, but you're indicating that the Windows command line parsing rul= es > are followed. So I assume the reality is that it is actually some mix of = the two. > Is the effective parsing logic implemented by Cygwin documented anywhere? If you start a Cygwin process from another cygwin process, then only POSIX rules are in effect. The bash shell parses its command line according to POSIX rules, creates an argv[] to pass to exec(), then cygwin1.dll manages to get that argv[], unscathed, to the new child process (bypassing Window's mechanisms), which uses the argv[] as-is. If you start a Windows process from a cygwin process, then cygwin1.dll must quote the arguments into a single concatenated string that will be reparsed in the manner that the Windows runtime expects, because the Windows process only gets a single string, not an argv[]. But cygwin should be providing the correct escaping so that windows then parses it back into the same intended argv[] (if not, that's a bug in cygwin1.dll). If you start a cygwin process from Windows, then cygwin1.dll is given only a single string, which it must parse into argv according to windows conventions (if it does not produce the same argv[] as a windows process using CommandLineToArgvW, then that's a bug in cygwin1.dll). But on top of that, if you are using cmd.exe to generate your command line, then you must use proper escaping, otherwise, cmd.exe can produce a command line that has unexpected quoting in the string handed to CommandLineToArgvW, and the Windows parsing when there are unbalanced quotes can be screwy (if it encounters a " inside an argument that was not quoted with ", then that groups remaining text into the same argument until a balanced " or end of string is encountered). So it is not always obvious at first glance if what you type in cmd.exe provides the argv[] that you intended, because of the two layers of interpretation (one from cmd to Windows, and one from Windows convention into argv[]). --=20 Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org --7hicqN08iJUshQ2ENEkwo3wI01RIjsM7i-- --YAZKN5rIgFnR3svaWeAn1iDu4DdWT33qr Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEccLMIrHEYCkn0vOqp6FrSiUnQ2oFAl1xkEQACgkQp6FrSiUn Q2oB1AgAiHv4cw+wOMJBhArbce1X82+BMzpEHYQqqbMklSxnBfDNulM8GK2pRDcJ vrh1/f3IJkaoddz58OchFCiLhHb13C/F67GLlCa8EFfDbcH1y5SRaIvZQv55Hvp8 f9ZFrDDMKrBcsWX7bxLOwFFcRrfE0tXL5Ykxi+jQjArnMYgVBt7zId4yS8suH9v+ EARDJSaK16bjrUf/38A4RqKT7OVSeqWTq5rVlrO0K9oLaEHxT6x7pcmvAF+WZmoE 7BNL9TPVJeyCnJh7Spdj5x/sVOQVX1NGnOVdyh/T9bCGKPf8vahvjBdX2e61Yiix bMwN3Kzc+AnynK5rThq1RwpXGoOvQQ== =N6zt -----END PGP SIGNATURE----- --YAZKN5rIgFnR3svaWeAn1iDu4DdWT33qr--