A better popen2
P at draigBrady.com
P at draigBrady.com
Fri Jun 25 12:26:01 EDT 2004
Donn Cave wrote:
> In article <40DB2889.60808 at draigBrady.com>, P at draigBrady.com wrote:
> ...
>
>>http://www.pixelbeat.org/libs/subProcess.py
>>
>>Perhaps this could be included in commands.py for e.g.?
>
>
> It looks pretty good to me. A couple of minor points:
>
> - dup2(a, sys.stdout.fileno()) -> dup2(a, 1)
doh! of course. I hate magic numbers
but what I did was certainly wrong.
> - execvp('/bin/sh', ['sh', '-c', cmd])
>
> I think that could be just execv(), since you've
> supplied a path already. But I really prefer the
> way Popen3 does it, where the input parameter is
> argv, not a shell command (and you do use execvp.)
I just copied the way Popen3 did it?
> Of course you can supply ['sh', '-c', cmd] as that
> parameter, but for me it's more often the case that
> the parameters are already separate, and combining
> them into a shell command is unnecessary and risky.
> (Don't support both, like Popen3 does - that was a
> mistake that seems to routinely leave people confused
> about how it works.)
fair enough.
> And I haven't really tried to verify the logic or anything,
> but it does look like the right idea to me.
>
> I will at least add it to my collection. I don't have
> it at hand and haven't looked at it for a while, but
> at one time I was thinking I would put together every
> one of these things that has come across comp.lang.python,
> might be a dozen or so but I don't think I have them all
> yet. (I don't think I have "task", good find.)
>
> The most conspicuous recent one was (I think) called
> popen5, and rumor has it, will be standard with 2.4,
> and will have the select functionality you need, not
> only on UNIX but also on Windows, where it isn't so
> trivial a feat.
Cool! I missed that: http://www.python.org/peps/pep-0324.html
I had a 10 second look at process.Popen.communicate() and it seems
to do much the same as I did, however it's missing a timeout
parameter like I implemented which I think is important.
> Other than the platform dependency issues, I think
> the main reason this wasn't in the core library from
> the beginning is that the problem is more complicated
> than the solution, if you know what I mean. Or, each
> programmer's itch seems to be in a slightly different
> place.
I aggree that the appropriate interface is hard to define
however I think we all agree that popen2 is definitely not it.
thanks a million,
Pádraig.
More information about the Python-list
mailing list