Subprocess with and without shell

[James T. Dennis]

George Sakkis <george.sakkis at gmail.com> wrote:
> On May 15, 5:30 am, Nick Craig-Wood <n... at craig-wood.com> wrote:

>> George Sakkis <george.sak... at gmail.com> wrote:
>>>  I'm trying to figure out why Popen captures the stderr of a specific
>>>  command when it runs through the shell but not without it. IOW:

>>>  cmd = [my_exe, arg1, arg2, ..., argN]
>>>  if 1: # this captures both stdout and stderr as expected
>>>      pipe = Popen(' '.join(cmd), shell=True, stderr=PIPE, stdout=PIPE)
>>>  else: # this captures only stdout
>>>      pipe = Popen(cmd, shell=False, stderr=PIPE, stdout=PIPE)

>>>  # this prints the empty string if not run through the shell
>>>  print "stderr:", pipe.stderr.read()
>>>  # this prints correctly in both cases
>>>  print "stdout:", pipe.stdout.read()

>>>  Any hints ?

>> Post an example which replicates the problem!

> I would, but the specific executable being spawned is not a python
> script, it's a compiled binary (it's not an extension module either;
> it's totally unrelated to python). I don't claim there is a bug or
> anything suspicious about Popen, but rather I'd like an explanation of
> how can a program display different behavior depending on whether it
> runs through the shell or not.

> George

 Well, I would try inspecting your environment ... in the shell
 and from within your Python process.  See if there's anything
 there.

 If run a command via an interactive shell and it behaves differently
 when run via Popen then see if perhaps it's doing something like
 checking to see if it's stdin, or stdout are TTYs (using the C
 library functions like isatty() for example).  You might try
 running the program under a Pexpect rather than SubProcess (since
 Pexpect will run the process with it's std* descriptors connected
 to pty devices).  Alternatively try running the program in a shell
 pipeline to see if it behaves more like you're seeing when you run
 it under Python.  (Since running it in the middle of a pipeline,
 perhaps with 2>&1 as well, is ensuring that all of the std* descriptors
 are connected to pipes.  (You could also run with 2>/tmp/some.FIFO
 after doing a mknod p /tmp/some.FIFO (Linux) or mkfifo /tmp/some.FIFO
 (BSD) to create the named pipe, of course).

 If none of that worked ... try running the program under stace,
 truss, ktrace or whatever system call tracing facility your OS
 provides ... or under gdb.




-- 
Jim Dennis,
Starshine: Signed, Sealed, Delivered