A better popen2

[P at draigBrady.com]

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.