pf_moore at 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/base/commandlinetoargvw.asp 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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4