DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; q=dns; s=
	default; b=NXWrF+Lma3NSLNwklA4vYnmZGPuUk5A2NVxn+sXoB7J1dWreIl4e9
	9vmII1r1+NaCk9RKUD2+QyiKYbOgtRlDHfPaCfJ5B4Yh6TIDqETT0LBxYvMrP+lj
	7LSua2e+gjp1pZxtV1CSgkJXtFbCwIL3JJUDZ0Ai5gz1JRpHfy5rPE=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Date: Fri, 19 Jun 2015 11:01:48 +0200
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: Arguments parsing in cygwin executables
Message-ID: <20150619090148.GT31537@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <CAMSC8GNk-V8qW3jKLOFayN8HRckOWdpwS26rzG_ofH4O3=s=og AT mail DOT gmail DOT com> <20150619084404 DOT GS31537 AT calimero DOT vinschen DOT de>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;	protocol="application/pgp-signature"; boundary="Y4/B1uKDHmWlpzsz"
Content-Disposition: inline
In-Reply-To: <20150619084404.GS31537@calimero.vinschen.de>
User-Agent: Mutt/1.5.23 (2014-03-12)

--Y4/B1uKDHmWlpzsz
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Jun 19 10:44, Corinna Vinschen wrote:
> Hi Sasha,
>=20
> On Jun 17 20:56, Sasha Unknown wrote:
> > Hello.
> >=20
> > =3D=3DPreamble=3D=3D
> > Some time ago I noticed that cygwin executables (e.g. bash, tar, echo
> > & so on) handle specially *, {} and some other symbols in
> > command-line, even when being invoked not from shell (e.g.
> > programmatic invocation or cmd.exe). After some googling, I found
> > CYGWIN=3Dnoglob setting, which fixed the issue. After enabling it I
> > hoped that cygwin executables will start parsing command-line in a
> > standard for Windows executables way (I am not talking about path
> > translation, only about handling special characters and splitting
> > command string into argv array).
> >=20
> > =3D=3DMain=3D=3D
> > It revealed that even with CYGWIN=3Dnoglob, cygwin executables parse
> > command line differently from other windows executables. (Again, I
> > underline: I'm talking about invocation from cmd.exe or programmatic
> > invocation, not invocation from bash.) Concretely, the 3rd and 4th
> > test-cases from here fail:
> > https://msdn.microsoft.com/en-us/library/windows/desktop/17w5ykft(v=3Dv=
s.85).aspx.
> > (BTW, ironically, with CYGWIN=3Dglob only 3rd test-case fails.)
>=20
> Uhm...I just tried it myself and independently of the CYGWIN=3Dglob
> setting only the 3rd test case fails for me.  Test case 4 works fine.
>=20
> > =3D=3DQuestions=3D=3D
> > So, questions are:
> > 1. Is this behavior intentional, or is it bug?
>=20
> The differences in argv processing when called from a non-Cygwin parent
> process have been discussed a couple of times in the last years, but I
> don't think there's a consensus if that's a bug or a feature.  The=20
> function hasn't seen any noticable changes since the year 2000, though,
> and any behavioral change *might* introduce backward incompatibilities
> with existing scripts...
>=20
> > 1a. If intentional: Maybe there is a way to force cygwin executables
> > to perform command-line parsing in windows-canonical way (i.e.
> > CommandLineToArgv-like)? (I am talking about splitting command string
> > into argv array, not about path translation.)
> > 2. In any case, could you point me to part of cygwin sources which is
> > responsible for this? (In case of intentionality -- to understand what
> > behavior I'm now forced to adopt to, in case of bug -- to possibly aid
> > fixing.)
>=20
> https://sourceware.org/git/gitweb.cgi?p=3Dnewlib-cygwin.git;a=3Dblob;f=3D=
winsup/cygwin/dcrt0.cc;h=3D738860d0ea92ef575755b9e1752a5c53c3ccaa97;hb=3DHE=
AD
>=20
> Look for function build_argv.
>=20
> If you're willing to take a stab at it to fix the aforementioned
> test case 3, I'm willing to include it.  As for how to contribute,
> see https://cygwin.com/contrib.html
>=20
> Just two points:
>=20
> - If the patch changes more than 10 lines, we need a copyright
>   assignment.  See https://cygwin.com/contrib.html, there's a standard
>   copyright assignment form you can simply send as signed PDF by mail to
>   the address given therein.
>=20
> - Please make sure to implement it so that we can switch back to the old
>   behaviour by checking some global bool variable ("bool old_argv" or so).
>   I'll then help adding the required code to allow doing that via the
>   CYGWIN environment variable for the (hopefully) rare cases which
>   require the old behaviour.
>=20
> > BTW, in CYGWIN=3Dglob mode, curly braces are handled wrongly
> > (c:\cygwin\echo.exe {aa} should return {aa}, not aa; because no , or
> > .. inside {}).
>=20
> I don't think so.  GLOB_BRACE globbing is meant to do brance globbing
> just as csh does.  This doesn't require a comma or anything else within
> the braces.  Try this in tcsh or even bash.  The underlying code is

No, not in bash.  I see what you mean.  Bash handles that differently
than [t]csh.  However, csh is the obvious role model for this behaviour,
so if I had to choose who's right and who's wrong, csh (and thus the
glob original BSD code) is the clear winner.

> (almost) stock FreeBSD code, btw.


Corinna

--=20
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

--Y4/B1uKDHmWlpzsz
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJVg9p8AAoJEPU2Bp2uRE+gadYQAIlQIgie4M1jVX6pCyLPrHWs
bPfi1sQwmJhw8JLfCLdYTXquyqA1BrcVssGlQzo7HpgwZACNEiYbyOo2jdzsTimi
U2311khVliFpXEPPJegroKF1xMcDPpYictH9/nW4aGkmUTMP3g304iZhPKlJk5Te
BqK95r7+Dw8RZPcYhQmDGDYd3DIvPINpoNDR2cGWM/ecV03OOgB/7McxFA0x7l3k
8fscZ3z0NgKj/rx2Duk/gb/p4RA3SLWVwqsJx0tjfM3QyLnls+6D69TZlACL1Swd
k1QfbNLbqQZGzgulMz7cRXUiUCoveDfttLMO88BWoglCPqDQzQbEBW+X8n7AvgQA
wBOpJZjR8klEFmZ8FfJzg3fdNFIVsu5jzc2tGdD6evhYldtD2oZ0bLm8bCdhPr86
w5LvGGunP5WGIdjsPsQFkUS3aQDH637nPX9q/JtCI0tTxCF7ym2tfd9Me10plhGt
TpaIB3OQPIgzpE2shvvfvG1OUw3n/al+8rEJsuf63b3jzA7+9UWAUDWfJ5jQo2M/
IcGb0UznIHskCarV4ThlLPZi3VlMUv/nLym7zEIEuAca3ZwRLUYPqy0+mH08lqLm
8To/8IoGhpQFTiB6tBgO9E7Gf7cd3x/DJ/SmYI2Ngk6ZfxIEJeYDBLuYuP+pfmo+
GfQ7h8VXQxNzxtuZPQON
=jE7f
-----END PGP SIGNATURE-----

--Y4/B1uKDHmWlpzsz--