From: Nobody on
On Sun, 31 Jan 2010 13:41:55 -0600, Tim Chase wrote:

> The previous absolute-path fails in cmd.exe for a variety of apps because
> the "/" is treated as a parameter/switch to the various programs.
> Fortunately, the Python path-handling sub-system is smart enough to do the
> right thing, even when Win32's internal handling is too dumb to behave:

Let's not conflate multiple issues:

1. Windows API functions almost invariably accept either \ or /.

2. Python functions just pass filename strings verbatim; they won't try to
"fix" them in cases where a specific separator is required (e.g. system(),
which calls cmd.exe or %COMSPEC%, which has its own requirements).

3. Command-line programs may treat / as indicating a switch, even in what
would normally be considered the middle of an argument.

4. Windows doesn't enforce the "char **argv" convention. Programs get
passed the literal command line as a single string, and are free to parse
it however they wish.

4a. Programs compiled with MSVC and using a main(argc, argv) interface
will have the command-line parsed as documented in:

http://msdn.microsoft.com/en-us/library/17w5ykft.aspx

Programs built with other compilers, programs using WinMain(), and
programs which use the "raw" command line may behave differently, and
certain Windows command-line programs (most notably those inherited from
DOS) *do* behave differently.

5. Python functions which accept command arguments as a list of strings
(e.g. subprocess.call()) will assemble a command string according to the
above specification. If you're invoking a program which doesn't follow
that specification, you'll need to pass the command-line as a string
rather than as a list of arguments.