Jason Lunz
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.