Prev: iglob performance no better than glob
Next: Meet Arab, Russian, American Singles From All Over The World
From: Nobody on 31 Jan 2010 16:52 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.
First
|
Prev
|
Pages: 1 2 3 Prev: iglob performance no better than glob Next: Meet Arab, Russian, American Singles From All Over The World |