En Sun, 01 Feb 2009 18:00:36 -0200, Andrew Parker <gbofs...@gmail.com>
escribió:
On Sun, Feb 1, 2009 at 1:46 PM, Andrew Parker <gbofs...@gmail.com> wrote:
I'm having some fun with Popen. I have the following line:
process = subprocess.Popen(command, stdout=subprocess.PIPE,
stderr=subprocess.STDOUT)
print process.stdout
Under normal circumstances, this displays:
<open file '<stdout>', mode 'w' at 0xb7f8e068>
However, I have a binary that I use to kick off this script, and when
that runs, it displays:
None
So, two questions:
1. What the heck is this binary doing that upsets Popen so much?
2. What can *my script* do to get around this problem.
Unfortunately I'm stuck using this binary, so its the python where I
have to solve this.
so, tracing through subprocess.Popen, I see that os.pipe() is being
invoked for stdout. This is returning (0, 3), and I assume the 0 is
conflicting with what python is assuming is stdin. Calling pipe()
before Popen gets around my problem, as the pipe the Popen gets then
returns (4,5) which Popen seems happy with.
Seems that "your binary" is closing stdin before running your script, so
the first available file descriptor is 0.
Sounds like a bug. Should I report this, or is it expected/known
behaviour?
It's hardly a Python error, and I don't think the subprocess module should
consider this very special case, but you may report it at
http://bugs.python.org/ anyway.
--
Gabriel Genellina
--
http://mail.python.org/mailman/listinfo/python-list
