[Pythonmac-SIG] interaction with OS X commands

[Bob Ippolito]

On Oct 18, 2004, at 19:51, eichin at metacarta.com wrote:

> Mmm, looks like subprocess.call() does what os.system should have done
> all along, namely what perl does - if you give it an array, it doesn't
> do any unsafe string or shell manipulation, it just slots the
> arguments into the relevant underlying syscall.  (On the other hand,
> spawnv already did that...)

and execv, etc.  popen and system are the problem children :)

> None of the PEP 324 examples deal with actual pipelines, though, so I
> can't tell yet if it'll help with my pipeline class (which does
> explicit pipe/fork/exec/wait and returns a list of the exit statuses
> of the entire pipe - and works with lists, not strings, so it's again
> argument-safe.)

Well Popen is a relatively low level primitive, if you want to do 
pipelines you have hooks to set the stdin/stdout/stderr filehandles.

> I actually use commands.getoutput on ifconfig in some code because
> it's a lot more *portable* than doing the GIFCONF ioctls, and if I'm
> not allowing any user specified arguments the call is safe enough (I
> can tell if it failed simply because the output is verbose enough that
> if the parser fails, Something Went Wrong and I can just report that.)
> For shell-script-equivalent stuff, it is actually *far* more readable
> than any of the Popen.communicate examples in the PEP, and that's
> worth a great deal in some contexts.  If anything, I'd like to see the
> stuff in commands implemented using subprocess, and then extended to
> handle list-arguments; ifconfoutput = commands.getoutput(["ifconfig", 
> "en0"])
> would be readable *and* safe, if it were implemented :-)

So write it and submit it.. it's pretty trivial stuff, the patch might 
even be accepted.. maybe not for 2.4, though.

-bob