[issue15408] os.fork/os.popen behaviour change between 2.7 and 3.2

[Zachary Ware]

Zachary Ware  added the comment:

Given that you both nearly agreed to "wont fix" 8 years ago and 2.7 is now EOL, 
I'm going to go ahead and close the issue that way :)

--
nosy: +zach.ware
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15408] os.fork/os.popen behaviour change between 2.7 and 3.2

[Richard Oudkerk]

Richard Oudkerk  added the comment:

A program which depends on the old behaviour would be broken on a 
non-refcounted implementation of Python, so I would be inclined to say "won't 
fix".

However, I think the following patch would restore the old behaviour

diff -r a970054a93fb Lib/os.py
--- a/Lib/os.py Mon Jul 16 18:30:03 2012 +0100
+++ b/Lib/os.py Mon Jul 23 19:12:38 2012 +0100
@@ -1004,6 +1004,13 @@
 # Helper for popen() -- a proxy for a file whose close waits for the process
 class _wrap_close:
 def __init__(self, stream, proc):
+# proc should be waited on when stream is garbage collected
+import weakref
+def callback(wr):
+proc._weakref = None   # break ref cycle
+proc.wait()
+proc._weakref = weakref.ref(stream, callback)
+proc.stdin = proc.stdout = None# proc must not keep stream alive
 self._stream = stream
 self._proc = proc
 def close(self):

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15408] os.fork/os.popen behaviour change between 2.7 and 3.2

[Walter Dörwald]

Walter Dörwald  added the comment:

So is this simply a documentation issue, or can we close the bug as "won't fix"?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15408] os.fork/os.popen behaviour change between 2.7 and 3.2

[Richard Oudkerk]

Richard Oudkerk  added the comment:

In Python 2.x, when the file object returned by popen() is garbage collected 
the process is automatically waited on, collecting the pid of the process.

In Python 3.x a wrapper object is used whose close method wait on the pid.  
This close method is *not* invoked when the wrapper is garbage collected.  
However, the set of dead pids cannot accumulate since dead pids get collected 
whenever os.popen()/subprocess.Popen() is used.

The old behaviour is only an advantage in a refcounted implementation of Python 
like CPython.  I am not sure that "fixing" the current behaviour is necessary.

Simply adding to the wrapper class a __del__() method which invokes close() 
will not work.  (One could instead use a weakref callback, but that is 
non-trivial.)

--
versions: +Python 3.3 -Python 3.2

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15408] os.fork/os.popen behaviour change between 2.7 and 3.2

[Richard Oudkerk]

Richard Oudkerk  added the comment:

Actually, if you replace

print(os.popen("uname").read())

with

f = os.popen("uname")
print(f.read())
f.close()

or

with os.popen("uname") as f:
print(f.read())

then things should work.  This is because f.close() waits for the pid.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15408] os.fork/os.popen behaviour change between 2.7 and 3.2

[Richard Oudkerk]

Richard Oudkerk  added the comment:

The problem is that os.wait() is returning when the wrong process exits.

You can fix this by specifying the pid you are waiting for by doing 
"os.waitpid(pid, 0)" instead of "os.wait()".

Arguably os.popen() and subprocess.communicate() etc should always reap the pid 
of the process they started.

--
nosy: +sbt

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15408] os.fork/os.popen behaviour change between 2.7 and 3.2

[Walter Dörwald]

New submission from Walter Dörwald :

The attached script behaves differently on Python 2.7.2 and Python 3.2.3.

With Python 2.7 the script runs for ca. 30 seconds and then I get back my 
prompt.

With Python 3.2 the script runs in the background, I get back my prompt 
immediately and can type shell commands.

Commenting out the call to uname() changes the behaviour of the script on 
Python 3.2 so that it behaves like on Python 2.7.

(This happens on both Max OS X 10.7 and Linux.)

--
files: gurk.py
messages: 165942
nosy: doerwalter
priority: normal
severity: normal
status: open
title: os.fork/os.popen behaviour change between 2.7 and 3.2
versions: Python 3.2
Added file: http://bugs.python.org/file26456/gurk.py

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com