This is the mail archive of the
mailing list for the Cygwin project.
Re: Command line processing in dcrt0.cc does not match Microsoft parsing rules
Greetings, Stephen Provine!
> The standard rules for Microsoft command line processing are documented here:
> 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:
> echo $1
> And the following invocation of bash.exe from a Windows command prompt:
> bash.exe test.sh foo\"bar
> The result is:
> When the expected result is:
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:
> 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:
> The behavior here is based on a detailed analysis of what command line parsing "should" be in Windows:
> It would be very nice if Cygwin followed the same procedure at startup.
> 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,
Saturday, August 31, 2019 11:27:38
Sorry for my terrible english...
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple