Mail Archives: cygwin/2004/09/07/11:20:25
Christopher Cobb <ccobb <at> email.com> writes:
>
> Brian Dessent <brian <at> dessent.net> writes:
> >
> > Interesting function. However, I found that it chokes if the name of
> > the command to run has spaces, even if they are properly quoted on the
> > command line, e.g.
> >
>
> That's interesting. I'm running Win XP and even with your patches I /still/
> get an error when a batch file path with spaces is given.
>
What I see is that this problem exists even from a cmd.exe window:
This works as expected:
C:\>type "C:\Documents and Settings\test.bat"
echo %1
C:\>"C:\Documents and Settings\test.bat" "Hello, world."
"Hello, world."
However, this does not work:
C:\>cmd /c "C:\Documents and Settings\test.bat" "Hello, world."
'C:\Documents' is not recognized as an internal or external command,
operable program or batch file.
The problem seems to be the /two/ sets of quotes. Removing the quotes around
"Hello, world." results in:
C:\>cmd /c "C:\Documents and Settings\test.bat" Hello, world.
C:\>echo Hello
Hello
This gets us to the batch file, but it loses the second argument. Just for the
record, this is the same (but undesired) behavior invoking the batch file
directly but without quotes on the arguments:
C:\>"C:\Documents and Settings\test.bat" Hello, world.
C:\>echo Hello
Hello
Conclusion: cmd.exe command line processing is brain dead.
Among the problems are that cmd.exe looks for /exactly/ one pair of quotes and
no more (see my previous message). And that (double) quotes are the /only/ way
of quoting spaces.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -