A better popen2

[Donn Cave]

In article <40DB2889.60808 at draigBrady.com>, P at draigBrady.com wrote:
...
> There are external solutions like the getCommandOutput recipe:
> http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/52296
> which has problems that I've commented on there.
> There are also very complex solutions like "subproc" from
> Ken Manheimer and "task" from Rob Hooft
> 
> Therefore I bit the bullet and wrote my own,
> with as simple an interface as I thought possible:
> 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())

    You want 1, not sys.stdout.fileno().  They should be
    the same, unless someone has been monkeying around
    with stdout, and in that case you must use 1.  (And
    of course likewise with stderr and stdin, mutatis
    mutando.)  After the exec, whatever stdout was is
    irrelevant and the new command will write to 1, read
    from 0, etc.

  - 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.)
    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.)

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.

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.

   Donn Cave, donn at u.washington.edu