RetroSearch Browse

Sat Oct 9 15:54:22 CEST 2004 · http://mail.python.org/pipermail/python-dev/2004-October/049288.html

astrand at 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

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from http://mail.python.org/pipermail/python-dev/2004-October/049288.html below:

[Python-Dev] Re: subprocess - updated popen5 module