pf_moore@yahoo.co.uk said:
Hence on Windows, a command line is the fundamental unit, whereas on Unix an argument list is fundamental.
Yes, you're right. I read up on CreateProcess(), GetCommandLine(), and CommandLineToArgvW() after posting. Interestingly, MS's sample code for CommandLineToArgvW is buggy because of confusion between the two interfaces. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/bas... Also, it can fail.
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.
So why does subprocess use cmdline2list() in the parent on unix to emulate the way a child subprocess might parse the string on windows? (But only if it's written in C, uses the MSC runtime, and uses the argv/argc handed to main() rather than calling GetCommandLine() itself). Why not emulate CommandLineToArgvW()? or something else entirely? I think it would be cleaner not to emulate anything at all.
The unix execv is just *different*. Both the Windows and the Unix interfaces have capabilities the other doesn't offer.
Well, the windows interface is a subset of the unix one. The length of argv on windows is limited to 1.
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!)
I can see that it's trying to be symmetric and orthogonal, but I don't think that the result is worth it in this case. In what scenario is the use of cmdline2list() really useful? Jason