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

2020-04-26 Thread 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 __

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

2012-07-23 Thread 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/L

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

2012-07-23 Thread 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 ___

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

2012-07-23 Thread 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* inv

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

2012-07-20 Thread 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.c

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

2012-07-20 Thread 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

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

2012-07-20 Thread 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 she