[issue6358] os.popen exit code inconsistent

James Abbatiello report at bugs.python.org
Sun Jun 28 23:31:30 CEST 2009


New submission from James Abbatiello <abbeyj at gmail.com>:

Start a process with os.popen() and then try to get its exit code by
closing the resulting file handle.  The value returned is inconsistent
between 2.x and 3.x.  Example:

Python 2.6.2 (r262:71605, Apr 14 2009, 22:40:02) [MSC v.1500 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> f = os.popen("exit 42", "r")
>>> f.close()
42


Python 3.1 (r31:73574, Jun 26 2009, 20:21:35) [MSC v.1500 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> f = os.popen("exit 42", "r")
>>> f.close()
10752
>>> divmod(10752, 256)
(42, 0)


The docs for 2.6.2 say that the return value is the exit status of the
process as returned by wait()
(http://docs.python.org/library/os.html#os.popen).  That's what 3.1 is
doing(*) but not what 2.6 has actually been doing.  In 2.6 the exit code
(not exit status) is returned; if the process didn't exit cleanly then
an exception is thrown.

The docs for 3.1 say that os.popen() is documented in the section "File
Object Creation" but it is not.
http://docs.python.org/3.1/library/os.html#process-management
http://docs.python.org/3.1/library/os.html#file-object-creation
It doesn't seem to be documented at all in 3.1 although it is mentioned
many times on that page.

Since os.popen() is mostly for backward compatibility, should the 3.x
behavior be changed to match the actual 2.6 behavior?

(*) It looks like 3.1 doesn't return the right value if the subprocess
is killed by a signal but I can't test this on win32.

----------
assignee: georg.brandl
components: Documentation, Library (Lib)
messages: 89792
nosy: abbeyj, georg.brandl
severity: normal
status: open
title: os.popen exit code inconsistent
versions: Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6358>
_______________________________________


More information about the Python-bugs-list mailing list