George Sakkis <[EMAIL PROTECTED]> wrote:
> On May 15, 5:30 am, Nick Craig-Wood <[EMAIL PROTECTED]> wrote:
>> George Sakkis <[EMAIL PROTECTED]> 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
--
http://mail.python.org/mailman/listinfo/python-list
