This is the mail archive of the
mailing list for the Cygwin project.
Re: syntax for Cygwin bash invoking Win apps
- From: Matt Wozniski <godlygeek at gmail dot com>
- To: cygwin at cygwin dot com
- Date: Wed, 9 Sep 2009 00:31:24 -0400
- Subject: Re: syntax for Cygwin bash invoking Win apps
- References: <email@example.com>
On Tue, Sep 8, 2009 at 11:30 PM, Ziser, Jesse wrote:
> Hello list,
> When I type a command in bash to invoke a Windows application (like cmd.exe,
> for example), I can't seem to find a pattern in the Windows command line that
> actually gets executed. Ordinary bash syntax does not seem to apply in
> general when the command is a Windows app, but rather, sometimes special
> characters are interpreted in a bash-like way, and sometimes not. So, I'm
> wondering what determines whether a quote mark or something gets interpreted
> or passed on.
I can't contend to be an expert on cmd.exe escaping, but I'll take the first
swing... And the MS docs found at  will probably be more useful
> Here are some examples:
> $ cmd /c echo "/?"
> Displays messages, or turns command-echoing on or off.
> ECHO [ON | OFF]
> ECHO [message]
> Type ECHO without parameters to display the current echo setting.
Falls under the expansion conditions mentioned at the "processing
quotation marks" section of the cmd manual; so it expands to run the
command 'echo' with the argument '/?'
> # OK, so I'm getting the Windows echo, not the bash echo. Good.
> # Moving on...
> $ cmd /c echo abc
> $ cmd /c echo "abc"
One set of quotes that is stripped, per the DOS rules ("If the previous
conditions are not met, string is processed by examining the first
character to verify whether or not it is an opening quotation mark. If
the first character is an opening quotation mark, it is stripped along
with the closing quotation mark. Any text following the closing
quotation marks is preserved."). Granted, that rule doesn't make a lot
of sense, but that's why we all prefer UNIX... >_>
> $ cmd /c echo "\"abc\""
> # Wahhh?!
Again, a weird MS quoting behavior. The "previous conditions" mentioned
above include "you use exactly one set of quotation marks". Here, you
didn't, so cmd is nice enough to not strip anything for you.
> Anyone who knows the explanation would make me very grateful. I've tried
> this with other Windows apps too, and the same weirdness seems to occur.
> On a related note, I've noticed what appears to be an automatic sort of
> half-bash invocation (but not quite?) or something when I run Cygwin commands
> from cmd.exe. For example,
>> c:\cygwin\bin\echo hi
Nothing bash about this... Calling c:/cygwin/bin/echo.exe with the
single argument 'hi'
>> c:\cygwin\bin\echo "hi"
Nor this; it expands to exactly the same call
>> c:\cygwin\bin\echo "\"hi\""
This one I'm not sure about, but I think the reason is that the above
crazy quoting rules only apply to "cmd /c" and "cmd /k", and that this
undergoes a different sort of escaping where it is transformed to a call
to echo.exe with just the argument '"hi"'. Should be easy enough to
test by using DOS echo instead of cygwin echo, but I don't have access
to Cygwin ATM.
>> c:\cygwin\bin\echo *
> myfile myotherfile yetanotherfile ...
Nothing bash-related about this, either. cmd.exe expanded the * to
a list of files, just like you'd expect. "echo *" should work fine in
DOS, even without any cygwin tools, so this just expanded to a call to
"echo.exe" with 3 arguments, "myfile", "otherfile", and
> And yet...
>> c:\cygwin\bin\echo $PATH
This one should make the most sense of all. cmd.exe doesn't expand
$ENVVAR (unix syntax for an environment variable), it expands %ENVVAR%
(dos syntax), so naturally $PATH is passed straight through. In
a normal unix environment, $PATH would be expanded by a shell like bash
or csh, which you've left out of that interaction; /bin/echo certainly
isn't expected to check its arguments for possible environment variables
and expand them itself.
> What the heck is going on? Are there any rules here at all? Sorry if I'm
> missing something dumb. And sorry for apologizing for it. And......
> Thanks in advance,
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple