[Python-Dev] Re: subprocess - updated popen5 module

[Paul Moore]

Jason Lunz <lunz at falooley.org> writes:

> I think I need to understand better the division of labor between parent
> and child on Windows when it comes to passing the command line during
> process creation.

It's simple. The parent passes a *command line*, and the child
retrieves it using the GetCommandLine API. There is no concept of argv
at the Windows level - it is implemented by the C runtime parsing the
return value of GetCommandLine() and passing the resulting arguments
to main().

Hence on Windows, a command line is the fundamental unit, whereas on
Unix an argument list is fundamental.

The biggest problem on Windows is that not all executables use the
Microsoft C runtime. Some use other C runtimes, others parse the
command line directly and don't use argv at all.

> I'd like to think that unix execv() is a superset of the interface
> offered by CreateProcess(), in that you can initialize your child's
> argv however you like without regard to whitespace or quoting.

It would be nice to think that, but it ain't true <wink>.

> So it would be best if it were possible to offer the execv()
> interface on both platforms if that's possible.

The unix execv is just *different*. Both the Windows and the Unix
interfaces have capabilities the other doesn't offer. And as a
result, it's not possible to offer an execv interface on Windows, at
least not without running the risk of garbling some commands.

Luckily, the oddball cases are rare. So 99% of the time, either
interface will do OK (os.system on Unix, os.spawnv on Windows). But
the 1% can be crucial - shell-exploit style security holes on Unix,
garbled commands on Windows.

I think Peter's approach of supporting both forms - a single string as
a command line, and list of strings as an argv list, and converting
both to the more natural OS-native form as needed, is sensible (I
would, I argued for it when he was developing it!)

Paul
-- 
Ooh, how Gothic. Barring the milk.