This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: popen spawned process may not write to stdout under windows
Type: behavior Stage:
Components: Windows Versions: Python 2.5
process
Status: closed Resolution: wont fix
Dependencies: Superseder:
Assigned To: Nosy List: georg.brandl, ggenellina, jafo, pmezard, pythonmeister
Priority: normal Keywords:

Created on 2007-10-31 09:59 by pmezard, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Messages (6)
msg56991 - (view) Author: Patrick Mézard (pmezard) Date: 2007-10-31 09:59
Let child.py be:
"""
import sys

sys.stdout.write('1:stdout\n')
sys.stdout.flush()
sys.stderr.write('2:stderr\n')
sys.stderr.flush()
sys.stdout.write('3:stdout\n')
sys.stdout.flush()
"""

and parent.py:
"""
import os

cmd = 'python child.py'
for l in os.popen(cmd):
    print l,
"""

Then running it:
"""
>python parent.py
1:stdout

>python
Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit
(Intel)] on win32
"""

I would have expected at least:
"""
1:stdout
3:stdout
"""
to be output, which actually happens if the stderr is nullified like
"python child.py 2>nul" in parent.py call.

Am I wrong ?
msg57201 - (view) Author: Gabriel Genellina (ggenellina) Date: 2007-11-07 15:48
(I think the title you meant was 
"popen spawned process may not 
write to stderr under windows")

The child is dying with IOError: 
[Errno 22] Invalid argument
at the sys.stderr.flush() call.

Neither the docs for os.popen nor 
the Linux man page for popen(3) 
say that stderr is redirected, so 
one would expect the handle to be 
inherited; the IOError looks like 
a bug.
Try using os.popen4 or 
popen2.popen4 or -the recommended 
choice- the subprocess module. 
Using the latter, this is the 
modified parent.py:

"""
import subprocess
cmd = 'python child.py'
p = subprocess.Popen(cmd, 
stdout=subprocess.PIPE)
for line in p.stdout:
  print ">>>", line,
print p.wait()
"""

and this is the output, as 
expected:

"""
2:stderr
>>> 1:stdout
>>> 3:stdout
0
"""

Note the 2:stderr line lacking the 
>>>, because it was printed 
directly by the child process onto 
the stderr handle inherited from 
its parent.
msg57259 - (view) Author: Stefan Sonnenberg-Carstens (pythonmeister) Date: 2007-11-08 16:38
the popen call does not redirect stderr.
If you do something like 2>null (windows) or 2>/dev/null (*nix) it will
_never_ get printed.
If you want to have stderr & stdout getting in via popen and thus stdout,
under *nix and windows you would do that:

command 2>&1

It is not popen to blame.
See this for reference:
http://netbsd.gw.com/cgi-bin/man-cgi?popen++NetBSD-current
msg57261 - (view) Author: Patrick Mézard (pmezard) Date: 2007-11-08 17:14
pythonmeister: I never expected stderr to be redirected, just *all
stdout* to be captured. But...

gagenellina: you are completely right about the failure. Still, this
issue happened with a real world application written in C, and
redirecting manually stderr to :NUL: solved it unexpectedly. I did not
expect spawned process behaviour to differ when its stderr is being
redirected.
msg63687 - (view) Author: Sean Reifschneider (jafo) * (Python committer) Date: 2008-03-17 17:34
We've discussed this at the PyCon sprints, and here's the concensus:

os.popen inherits the parents stderr, and on Windows there is not an
existing valid stderr by default.  So the parent should, to be
compatible with the Windows environment, create stderr or use popen2.

However, popen is deprecated.  The best solution would be to use
subprocess module which is defined to do the right thing in this case. 
popen is not.

Because popen is deprecated, we are going to leave this behavior and
documentation as it is.
msg69829 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2008-07-16 20:40
Did you want to close this, Sean?
History
Date User Action Args
2022-04-11 14:56:27adminsetgithub: 45707
2008-12-05 09:46:32georg.brandlsetstatus: open -> closed
2008-07-16 20:40:52georg.brandlsetnosy: + georg.brandl
messages: + msg69829
2008-03-17 17:34:05jafosetpriority: normal
resolution: wont fix
messages: + msg63687
nosy: + jafo
2007-11-08 17:14:30pmezardsetmessages: + msg57261
2007-11-08 16:38:46pythonmeistersetnosy: + pythonmeister
messages: + msg57259
2007-11-07 15:48:51ggenellinasetnosy: + ggenellina
messages: + msg57201
2007-10-31 09:59:43pmezardcreate