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-10 22:01 Message: Logged In: YES user_id=7887 Interesting. I was running tests directly most of the times and also in verbose mode, which indeed was hiding the problem that would happen when stdout is replaced. Now, one thing I wonder is about this: http://www.python.org/dev/buildbot/all/g4%20osx.4%20trunk/builds/1424/step-test/0 Why is it failing? In the first run, when all buildbots were broken, this is what was happening. It does look like tests are succeeding, and the implementation is the same as the currently committed one, but buildbot still says it's broken for some reason, and no error messages. Strange. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2006-09-10 09:53 Message: Logged In: YES user_id=21627 How did you run the test cases yourself? They should have failed for you as well; buildbot has nothing to do with that. ---------------------------------------------------------------------- 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 _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
