By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,621 Members | 1,101 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,621 IT Pros & Developers. It's quick & easy.

Subprocess with and without shell

P: n/a
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 ?

George

May 15 '07 #1
Share this Question
Share on Google+
3 Replies


P: n/a
George Sakkis <ge***********@gmail.comwrote:
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!

My effort works as expected

-- z.py ----------------------------------------------------
#!/usr/bin/python
from subprocess import Popen, PIPE
cmd = ["./zz.py"]
for i in range(2):
if i: # this captures both stdout and stderr as expected
print "With shell"
pipe = Popen(' '.join(cmd), shell=True, stderr=PIPE, stdout=PIPE)
else: # this captures only stdout
print "Without shell"
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()
---zz.py----------------------------------------------------
#!/usr/bin/python
import sys
print >>sys.stdout, "Stdout"
print >>sys.stderr, "Stderr"
------------------------------------------------------------

Produces

$ ./z.py
Without shell
stderr: Stderr

stdout: Stdout

With shell
stderr: Stderr

stdout: Stdout

--
Nick Craig-Wood <ni**@craig-wood.com-- http://www.craig-wood.com/nick
May 15 '07 #2

P: n/a
On May 15, 5:30 am, Nick Craig-Wood <n...@craig-wood.comwrote:
George Sakkis <george.sak...@gmail.comwrote:
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
May 15 '07 #3

P: n/a
George Sakkis <ge***********@gmail.comwrote:
On May 15, 5:30 am, Nick Craig-Wood <n...@craig-wood.comwrote:
>George Sakkis <george.sak...@gmail.comwrote:
>> 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

Jun 29 '07 #4

This discussion thread is closed

Replies have been disabled for this discussion.