On 2019-09-06 13:35, Andrey Repin wrote: > CMD escape character is ^, not \
You are correct about the cmd.exe interpretation, so my test cases were buggy, but Go invokes other executables using CreateProcess directly and is not subject to the additional set of command line processing rules that are used by cmd.exe. If you see the last exchange with Eric, I think it is clear that there is a case missing in the Cygwin processing rules that becomes a problem when a calling process directly reverses the rules, specifically when an argument value does not itself need to be quoted but it has a double quote in the value. This is rule 4 in what I found to be the most definitive reference: http://daviddeley.com/autohotkey/parameters/parameters.htm#WINCRULESCHANGE And see the fourth example in section 5.4. However, the *safest* way to construct a command line is to avoid this case and make sure to always double quote an argument that contains double quotes. The official algorithm from a Microsoft source was previously posted by Eric: https://blogs.msdn.microsoft.com/twistylittlepassagesallalike/2011/04/23/everyone-quotes-command-line-arguments-the-wrong-way/ Interesting that there's actually nothing in this article that specifically means it *shouldn't* be ok to do what the Go algorithm does, it just happens to be simpler if you don't worry about that case. FWIW, .NET Core uses this algorithm: https://github.com/dotnet/corefx/blob/master/src/Common/src/CoreLib/System/PasteArguments.cs Which I think is probably pretty good validation that it's the right one to use. So, the outcome of all of this is that Go should probably update their logic as it's based on the wrong official source. I plan to follow up there. If there is any interest in the future to correct the parsing behavior in Cygwin, the information needed to do that is in this thread. Personally, I think that if Cygwin fixes the problem it's easier to recompile all those binaries than try to locate all potential source calling processes to make sure they follow the right algorithm (Go isn't right, what about Node, Python, etc...) But I'm not going to push on this point as I can work around it for my case. Thanks, Stephen -----Original Message----- From: Andrey Repin <anrdae...@yandex.ru> Sent: Friday, September 6, 2019 1:35 PM To: Stephen Provine <step...@microsoft.com>; cygwin@cygwin.com Subject: Re: Command line processing in dcrt0.cc does not match Microsoft parsing rules Greetings, Stephen Provine! > On 2019-09-04 23:29, Brian Inglis wrote: >> As standard on Unix systems, just add another level of quoting for >> each level of interpretation, as bash will process that command line, >> then bash will process the script command line. > 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. Called from within Cygwin, the behavior is correct: Again, fully expected. > $ bash -x script.sh foo bar\"baz bat > + echo foo > foo > + echo 'bar"baz' > bar"baz > + echo bat > bat > Can you explain this difference? CMD escape character is ^, not \ > The reason I ask is that if this worked, the way Go constructs the > command line string would be just fine. No. -- With best regards, Andrey Repin Friday, September 6, 2019 23:33:46 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
