Command line processing in dcrt0.cc does not match Microsoft parsing rules

[Eric Blake]

On 9/5/19 1:31 PM, Stephen Provine via cygwin wrote:
> My mistake - I'm very aware of the quoting rules, yet in my test script for this
> scenario I forgot to quote the arguments. However, if POSIX rules are being
> implemented, there is still something I didn't expect. Here's my bash script:
> 
> #!/bin/bash
> echo "$1"
> echo "$2" 
> echo "$3"
> 
> And I invoke it like this from a Windows command prompt:
> 
> C:\> bash -x script.sh foo bar\"baz bat
> + echo foo
> foo
> + echo 'bar\baz bat'
> bar\baz bat
> + echo ''
> 
> Not expected.

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

https://blogs.msdn.microsoft.com/twistylittlepassagesallalike/2011/04/23/everyone-quotes-command-line-arguments-the-wrong-way/

Perhaps you meant to try:

c:\> bash -x script.sh foo ^"bar\^"baz^" bat

> Called from within Cygwin, the behavior is correct:
> 
> $ bash -x script.sh foo bar\"baz bat
> + echo foo
> foo
> + echo 'bar"baz'
> bar"baz
> + echo bat
> bat

Moral of the story: POSIX rules are saner than cmd rules.

> 
> Can you explain this difference? The reason I ask is that if this worked,
> the way Go constructs the command line string would be just fine.

If Go is not constructing the command line string in a manner that
matches that blog post, the bug would be in Go.  Presumably, Cygwin is
correctly quoting things any time it calls into a non-Cygwin process
(but if not, give us a test case for us to patch cygwin, or even better
submit the patch).

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://cygwin.com/pipermail/cygwin/attachments/20190905/3295757a/attachment.sig>