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=P/qFGX9Br8hIEB4VEZ1Bws5yTPUuH8+8eYc94pFoj0gXNXKerTdRe
	YAzQsScRAvdrOovhNcDBjNSJZo4VS/GideRdL9tYHj7bMU/hpLzNia370pCHdu+6
	n0yA2INSsEQPeksAXibPcPKuZAa+k+dHuIs07gcCdeuMtiVLyZrUhQ=
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 10:44:04 +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: <20150619084404.GS31537@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>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;	protocol="application/pgp-signature"; boundary="/xevKuQXtvXNcizp"
Content-Disposition: inline
In-Reply-To: <CAMSC8GNk-V8qW3jKLOFayN8HRckOWdpwS26rzG_ofH4O3=s=og@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)

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

Hi Sasha,

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=3Dvs.=
85).aspx.
> (BTW, ironically, with CYGWIN=3Dglob only 3rd test-case fails.)

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.

> =3D=3DQuestions=3D=3D
> So, questions are:
> 1. Is this behavior intentional, or is it bug?

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

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

https://sourceware.org/git/gitweb.cgi?p=3Dnewlib-cygwin.git;a=3Dblob;f=3Dwi=
nsup/cygwin/dcrt0.cc;h=3D738860d0ea92ef575755b9e1752a5c53c3ccaa97;hb=3DHEAD

Look for function build_argv.

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

Just two points:

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

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

> BTW, in CYGWIN=3Dglob mode, curly braces are handled wrongly
> (c:\cygwin\echo.exe {aa} should return {aa}, not aa; because no , or
> .. inside {}).

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
(almost) stock FreeBSD code, btw.


Thanks,
Corinna

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

--/xevKuQXtvXNcizp
Content-Type: application/pgp-signature

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

iQIcBAEBCAAGBQJVg9ZTAAoJEPU2Bp2uRE+gzx4QAJK83p02Jcq8zLkYBUcMs/eL
U52AtsGG+6WP+bmf4876uzhUCxuvVovPu+YLm6eedELokrYDQczGZ3X2X7myqfO0
1an4gZhRbZ++SmvRy85NgWg7tkw4Jt3xfLGldzfvUtPdJYyInZdSJrPIpqx7ukQk
o1aTV94OP5UzfcpZNQHZa7LBvV3DHfUwpG2YskF+jAufIfd/vGBQcHfs8uCB2kZJ
ovNIVsjTeMiRvbyc3EG2ucSTLGPLCniu08iqYBhtYNr0YyPf0TcpfMn5HkC+L+1V
aL8Y4KUwj86XUcuesWn+2EIMKqLt6YxaoDdcJI8BsDNkk6XjJ+M2mbydc/XiMbjM
DDD+jbRfIUMnTc2/XvDqILiWsTi9bh2nrqJFJiNAjdBV/miqQ1ouautBOMZRnthQ
s402XzI6ckWqMQIRdlsF01muWdi+WUN7oaQsnBM51Ci2/gxtmVyWxlo4C0QQH71+
hp0TN6LLlwQASf/xAo1basAUjQpbthbOL+Wi1Hnf2SCFyaK+7AvY07qCEiU6S0pc
EdyzBr/ntSFhUoVawjQdQbk1AOIAW0e2VEyUF0l+htTdAtuA9LDjJru2eOPft64X
Qw5JuJAxkCQxH1csUXYZ8GMlom76O3068iWLqPEbcW3d9hfyBlamVYGV2ITOvgpj
DZULhw2vRcqm2qRHD+9y
=Nk1R
-----END PGP SIGNATURE-----

--/xevKuQXtvXNcizp--