astrand@lysator.liu.se said:
...which is slighly nicer. The drawback with callv is that it does not allow specifying the program and it's arguments as a whitespace-separated string: The entire (first) string would be intepreted as the executable. So, you cannot do:
subprocess.callv("somewindowsprog.exe some strange command line")
because then the system would try to execute a program called "somewindowsprog.exe some strange command line", which doesn't exist. You cannot do this either:
subprocess.callv("somewindowsprog.exe", "some", "strange", "command", "line")
...if somewindowsprog.exe doesn't use the MS C runtime argument rules.
I'm not sure I understand what the MSC runtime has to do with the naming of call/callv. Your examples don't work with call either, right? Their call() equivalents: subprocess.call(["somewindowsprog.exe some strange command line"]) subprocess.call(["somewindowsprog.exe", "some", "strange", "command", "line"]) are just as broken, no? Overall, I agree that callv() is superfluous. In my programming, I always end up using the "v" variants of exec functions, because there's always _something_ you do to the command line first, and it's easier to handle arguments as a list. [The above paragraph makes my point: "I always use execv(), so we should drop subprocess.callv()?" The naming hurts my poor brain.] Jason