A
good while ago, I discussed how the
idiosyncratic command-line parsing rules in
cmd.exe
can hurt code which
uses C runtime APIs such as
system,
and how to soothe the pain using mildly counterintuitive, but reasonably
simple quoting rules:
- Quote the command
- Quote all arguments
- If both the command and at least one of the arguments contain blank
characters, quote the whole command line as well.
This works for almost all situations except if you use
start:
C:\>start /b "c:\Program Files\Microsoft Visual Studio 8\Common7\Tools\Bin\uuidgen"
-ofoobar.txt
Try the above in a command prompt (everything in one line!):
"The system cannot find the file -ofoobar.txt".
When asking for syntax help (
start /?
), we get:
I:\>start /?
Starts a separate window to run a specified program or command.
START ["title"] [/D path] [/I] [/MIN] [/MAX] [/SEPARATE | /SHARED]
[/LOW | /NORMAL | /HIGH | /REALTIME | /ABOVENORMAL | /BELOWNORMAL]
[/AFFINITY <hex affinity>] [/WAIT] [/B] [command/program]
[parameters]
"title" Title to display in window title bar.
...
Note the optional
title argument and how it can create a syntactical ambiguity.
In "
start some command", which part of the command line is the title and
which is the command? This may or may not be the reason why
start
trips over
command names which contain blank characters - but the optional title argument
also provides the workaround for the problem:
C:\>start "eureka" /b "c:\Program Files\Microsoft Visual Studio 8\Common7\Tools\Bin\uuidgen"
-ofoobar.txt
In fact, an empty title string will do just as well:
C:\>start "" /b "c:\Program Files\Microsoft Visual Studio 8\Common7\Tools\Bin\uuidgen"
-ofoobar.txt
The above example is a little contrived - but the problem did in fact
affect some customers
recently when we changed installation paths for our products at CoCreate.
to top