[ python-Bugs-1531862 ] subprocess.Popen(cmd, stdout=sys.stdout) fails
SourceForge.net
noreply at sourceforge.net
Thu Sep 7 02:50:02 CEST 2006
Bugs item #1531862, was opened at 2006-07-31 16:53
Message generated for change (Comment added) made by niemeyer
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531862&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
>Status: Closed
Resolution: None
Priority: 5
Submitted By: John A Meinel (jfmeinel)
Assigned to: Gustavo Niemeyer (niemeyer)
Summary: subprocess.Popen(cmd, stdout=sys.stdout) fails
Initial Comment:
I'm currently using subprocess.Popen() to run a
command, and I allow the caller to specify where the
output should go.
One valid output is to send it to sys.stdout (fileno == 1)
The subprocess module seems to unconditionally close
stdout if a file handle is passed (even if it stdout).
Compare:
python -c "import subprocess,sys; \
subprocess.Popen(['echo', 'hello'])"
versus
python -c "import subprocess,sys; \
subprocess.Popen(['echo', 'hello'], stdout=sys.stdout)"
or even
python -c "import subprocess,sys; \
subprocess.Popen(['echo', 'hello'], stdout=1)"
The first one prints 'hello' as expected.
The latter two give an error:
echo: write error: Bad file descriptor
Attached is a possible patch to subprocess.py
----------------------------------------------------------------------
>Comment By: Gustavo Niemeyer (niemeyer)
Date: 2006-09-07 00:50
Message:
Logged In: YES
user_id=7887
Problem fixed again in 51797 (trunk) and 51794 (2.5), after
removing tests which were offending buildbot due to
sys.stdout being set to a StringIO.
----------------------------------------------------------------------
Comment By: Gustavo Niemeyer (niemeyer)
Date: 2006-09-06 12:52
Message:
Logged In: YES
user_id=7887
Notice that in all buildbots that reported the failure,
subprocess tests still pass correctly.
----------------------------------------------------------------------
Comment By: Gustavo Niemeyer (niemeyer)
Date: 2006-09-06 12:48
Message:
Logged In: YES
user_id=7887
Wow.. this is strange. I don't see any reason why the build
bots would break with this change, except for the reason
that the test needs to output data to stdout/stderr to check
if it's working or not. Is the buildbot checking these
somehow? Is there any additional information about these
failures?
----------------------------------------------------------------------
Comment By: Neal Norwitz (nnorwitz)
Date: 2006-09-06 03:59
Message:
Logged In: YES
user_id=33168
I have reverted both of these changes since all the
buildbots were broken.
----------------------------------------------------------------------
Comment By: Neal Norwitz (nnorwitz)
Date: 2006-09-06 02:34
Message:
Logged In: YES
user_id=33168
This change has broken many (all?) of the buildbots.
http://www.python.org/dev/buildbot/all/
----------------------------------------------------------------------
Comment By: Gustavo Niemeyer (niemeyer)
Date: 2006-09-06 02:06
Message:
Logged In: YES
user_id=7887
Fixed in 51758, backported to 2.5 in 51759.
----------------------------------------------------------------------
Comment By: Gustavo Niemeyer (niemeyer)
Date: 2006-09-06 01:44
Message:
Logged In: YES
user_id=7887
Neal, I'm preparing a patch which fixes this problem as well.
Anthony, we should really be checking fd numbers, since
they're the ones dup'ed in the child. If sys.stdout has a
fileno() not in (0, 1, 2), that's not an issue.
----------------------------------------------------------------------
Comment By: Anthony Baxter (anthonybaxter)
Date: 2006-08-16 04:16
Message:
Logged In: YES
user_id=29957
Making it check for particular FD numbers is a bad idea.
Instead, it should check that any FD that's being closed
isn't in the set
(sys.stdin.fileno(), sys.stdout.fileno(), sys.stderr.fileno())
----------------------------------------------------------------------
Comment By: Neal Norwitz (nnorwitz)
Date: 2006-08-16 04:11
Message:
Logged In: YES
user_id=33168
If stderr == stdout, this patch won't fix that, will it?
Shouldn't you add 1, 2 to the blacklist for stderr? (The
patch adds 2, I think 1 may also be required.)
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531862&group_id=5470
More information about the Python-bugs-list
mailing list