os.system vs subprocess

[Christian Heimes]

Nate wrote:
> Thanks for your response. Related to this talk about shells, maybe you
> could point me towards a resource where I could read about how windows
> commands are processed w/w/o shells?  I guess I assumed all subprocess
> commands were intepreted by the same thing, cmd.exe., or perhaps the
> shell.

The subprocess module never uses the shell unless you tell it so. On
Unix the modules uses fork() the exec*() familiy to create a new
process. On Windows it's the CreateProcess() api.

If you want to read about the Windows stuff then have fun at
http://msdn.microsoft.com/ ;)

> I guess this also ties in with me wondering what the whole subprocess
> Popen instantiation encompassed (the __init__ of the subprocess.Popen
> class?).

It does *a lot* of stuff. The subprocess module tries very hard to
create an easy to use interface that abstracts all OS specific traps
very well. Most of the subprocess module is written in Python but that
doesn't mean it's easy to understand. Have fun again!

> I don't think I need stdin, stdout, stderr as pipes, I just was faced
> with several options for how to capture these things and I chose
> subprocess.PIPE.  I could also os.pipe my own pipes, or create a file
> descriptor in one of a couple of ways, right?  I'm just unclear on
> which method is preferable for me.  All I want to do is pull the first
> 2 lines from the output before gmapcreator.jar finishes.  The first 2
> lines of output are always the same except a few numbers.

os.pipe() are suffering from the same issue as subprocess.PIPE. In fact
the PIPE constant tells subprocess to use OS specific pipes. If you
don't read from all pipes simultaneously one pipe may get filled up to
its buffer limit and both programs block.

As long as you use just one PIPE or the communicate() method then
nothing can get wrong.

Christian