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:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
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:	<MWHPR21MB08452919F35B1B0C5F0EB4DCB9BD0 AT MWHPR21MB0845 DOT namprd21 DOT prod DOT outlook DOT com> <MWHPR21MB0845F78385792965A94E0CD9B9BD0 AT MWHPR21MB0845 DOT namprd21 DOT prod DOT outlook DOT com> <MWHPR21MB084508155AB621C7AD81309CB9B90 AT MWHPR21MB0845 DOT namprd21 DOT prod DOT outlook DOT com> <MWHPR21MB08456D9F03AF8BD450E6AB2EB9B80 AT MWHPR21MB0845 DOT namprd21 DOT prod DOT outlook DOT com> <MWHPR21MB0845282E7582DC95ADF0F140B9BB0 AT MWHPR21MB0845 DOT namprd21 DOT prod DOT outlook DOT com> <MWHPR21MB084583452E7C41D0792C739EB9BB0 AT MWHPR21MB0845 DOT namprd21 DOT prod DOT outlook DOT com>
From:	Eric Blake <eblake AT redhat DOT com>
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:	<MWHPR21MB084583452E7C41D0792C739EB9BB0@MWHPR21MB0845.namprd21.prod.outlook.com>
X-IsSubscribed:	yes

--YAZKN5rIgFnR3svaWeAn1iDu4DdWT33qr
Content-Type: multipart/mixed; boundary="7hicqN08iJUshQ2ENEkwo3wI01RIjsM7i";
 protected-headers="v1"
From: Eric Blake <eblake AT redhat DOT com>
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: <MWHPR21MB08452919F35B1B0C5F0EB4DCB9BD0 AT MWHPR21MB0845 DOT namprd21 DOT prod DOT outlook DOT com>
 <MWHPR21MB0845F78385792965A94E0CD9B9BD0 AT MWHPR21MB0845 DOT namprd21 DOT prod DOT outlook DOT com>
 <MWHPR21MB084508155AB621C7AD81309CB9B90 AT MWHPR21MB0845 DOT namprd21 DOT prod DOT outlook DOT com>
 <MWHPR21MB08456D9F03AF8BD450E6AB2EB9B80 AT MWHPR21MB0845 DOT namprd21 DOT prod DOT outlook DOT com>
 <MWHPR21MB0845282E7582DC95ADF0F140B9BB0 AT MWHPR21MB0845 DOT namprd21 DOT prod DOT outlook DOT com>
 <MWHPR21MB084583452E7C41D0792C739EB9BB0 AT MWHPR21MB0845 DOT namprd21 DOT prod DOT outlook DOT com>
In-Reply-To: <MWHPR21MB084583452E7C41D0792C739EB9BB0 AT MWHPR21MB0845 DOT namprd21 DOT prod DOT outlook DOT com>


--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--

- Raw text -