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:reply-to:message-id:to:subject
	:in-reply-to:references:mime-version:content-type
	:content-transfer-encoding; q=dns; s=default; b=Jkou3s3VyaqhJ6nc
	6SPL6Fhm/FhHffv3c4jPC6qKunGASNFJWSU2pY6d+GVFyoBwAMOrGKbPTICUGuVq
	hieEv/SLTWE3xbtyaPhZjH5L73nO9sXLmubzNi3lbLCRY5CaC4M90lhwSLWjiPBj
	VHt3KLsOeIZIAOxyhAyBMS7vCOk=
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: Sat, 31 Aug 2019 12:23:29 +0300
From: Andrey Repin <anrdaemon AT yandex DOT ru>
Reply-To: cygwin AT cygwin DOT com
Message-ID: <127324731.20190831122329@yandex.ru>
To: Stephen Provine <stephpr AT microsoft DOT com>, cygwin AT cygwin DOT com
Subject: Re: Command line processing in dcrt0.cc does not match Microsoft parsing rules
In-Reply-To: <MWHPR21MB08452919F35B1B0C5F0EB4DCB9BD0@MWHPR21MB0845.namprd21.prod.outlook.com>
References: <MWHPR21MB08452919F35B1B0C5F0EB4DCB9BD0 AT MWHPR21MB0845 DOT namprd21 DOT prod DOT outlook DOT com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Greetings, Stephen Provine!

> The standard rules for Microsoft command line processing are documented here:

>     https://docs.microsoft.com/en-us/previous-versions/17w5ykft(v=vs.85)

> The Cygwin code for command line processing is in dcrt0.cc, function build_argv.

> The behaviors do not match. For instance, given a test.sh script like this:

>     #!/bin/bash
>     echo $1

> And the following invocation of bash.exe from a Windows command prompt:

>     bash.exe test.sh foo\"bar

> The result is:

>     foo\bar

> When the expected result is:

>     foo"bar

I would actually expect parsing error, but I guess, CMD gives you some slack.
Then, the expected result is either 'foo\"bar' or 'foo\bar', since in CMD, the
escape character is a caret (^).

> As a workaround, you can achieve the expected result using:

>     bash.exe test.sh "foo\"bar"

> Which is great until you use a language like Go to shell exec the command
> line, and don't have control over how the command line string is generated
> from an original set of arguments. See:

>     https://github.com/golang/go/blob/master/src/syscall/exec_windows.go#L86

> Go just reverses the Microsoft standard rules in the most efficient manner
> possible, but those command lines don't parse correctly in Cygwin processes.

> Go implements a pretty definitive command line parsing algorithm as a
> replacement for the CommandLineToArgv function in shell32.dll:

>    
> https://github.com/golang/go/commit/39c8d2b7faed06b0e91a1ad7906231f53aab45d1

> The behavior here is based on a detailed analysis of what command line parsing "should" be in Windows:

>     http://daviddeley.com/autohotkey/parameters/parameters.htm#WINARGV

> It would be very nice if Cygwin followed the same procedure at startup.

> Thanks,
> Stephen


> --
> Problem reports:       http://cygwin.com/problems.html
> FAQ:                   http://cygwin.com/faq/
> Documentation:         http://cygwin.com/docs.html
> Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple


-- 
With best regards,
Andrey Repin
Saturday, August 31, 2019 11:27:38

Sorry for my terrible english...


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple