Windows 2000, Python 2.0.1, 2.1.1, 2.2.

When a negative return code is received by the os.popen
() family, an IOError is raised when the last pipe from the 
process is closed.

The following code demonstrates the problem:

import sys
import os
import traceback

if __name__ == '__main__':

    if len(sys.argv) == 1:
        
        try:
            r = os.popen('%s %s %s' % (sys.executable, 
sys.argv[0], -1,))
            r.close()
        except IOError:
            traceback.print_exc()

        try:
            w, r = os.popen2('%s %s %s' % 
(sys.executable, sys.argv[0], -1,))
            w.close()
            r.close()
        except IOError:
            traceback.print_exc()

        try:
            w, r, e = os.popen3('%s %s %s' % 
(sys.executable, sys.argv[0], -1,))
            w.close()
            r.close()
            e.close()
        except IOError:
            traceback.print_exc()

    else:
        sys.exit(int(sys.argv[1]))

---------- Run ----------
Traceback (most recent call last):
  File "Q:\Viper\src\webvis\tests\test.py", line 11, in ?
    r.close()
IOError: (0, 'Error')
Traceback (most recent call last):
  File "Q:\Viper\src\webvis\tests\test.py", line 18, in ?
    r.close()
IOError: (0, 'Error')
Traceback (most recent call last):
  File "Q:\Viper\src\webvis\tests\test.py", line 26, in ?
    e.close()
IOError: (0, 'Error')

Logged In: YES 
user_id=44345

Attached Tim's code so it's more readily accessible to testers.
BTW, works fine for me on Linux.

Logged In: YES 
user_id=6380

I suppose this is one for Mark Hammond...

Logged In: YES 
user_id=14198

I'm not sure what to do about this.  Python internally
checks for -1 from the close function.  The safest thing to
do would be to translate the return code from -1 to
something else.  Changing the fclose semantics to check for
PyErr_Occurred is another alternative, but doesn't seem that
reasonable just for this.  Any thoughts?

Logged In: YES 
user_id=6380

How about changing the line "result = exit_code;" in
_PyPclose() to truncate the value to the lower 16 bits,
ensuring it is always >= 0? I think that should do it.

Logged In: YES 
user_id=14198

I tried truncating as you suggest, and this works fine -
although it gives different results than Linux.  Digging
deeper, I found for linux:
"""
The value from the wait() system call is split into three parts
mask 0xff00 is the exit status
mask 0x007f is the signal causing the exit
mask 0x0080 is the cord dumped flag in combination with a signal
"""

To get the same results as Linux for negative exit codes, it
seems:
         result = (int)((exit_code & 0x000000FF) << 8);

Will do the job.  Counter-intuitively, this will make
sys.exit(-1) yield an exit code of 65280, but this exactly
what happens on Linux.

Should we try and strive for compatibility within Python, or
compatibility with the host OS?  I lean towards
compatibility with Linux - if they want win32 specific
stuff, use win32 specific code.

Thoughts?

Logged In: YES 
user_id=6380

Yeah, that behavior is not just Linux, but any sane Unix
(although the POSIX standard abstracts it away in macros). I
think it's right to do that.

Logged In: YES 
user_id=113328

Do you propose to implement all of the WIFEXITED,
WEXITSTATUS series of functions for Windows as well?
Expecting people to unpack the return value manually -
especially Windows users who won't be aware of the Unix
heritage of the format - is probably unreasonable.

If you implement the W... functions, I'm OK with this
change. Otherwise I'm -1. After all, many uses of popen are
probably to run non-portable programs anyway, so portability
is only one aspect of the issue... 

Current output on XP with 2.5.1:

D:\>test.py
Traceback (most recent call last):
  File "D:\test.py", line 12, in <module>
    r.close()
IOError: [Errno 0] Error
Traceback (most recent call last):
  File "D:\test.py", line 20, in <module>
    r.close()
IOError: [Errno 0] Error
Traceback (most recent call last):
  File "D:\test.py", line 29, in <module>
    e.close()
IOError: [Errno 0] Error

os.popen* are deprecated, we should use subprocess now... could you
please try what happens with this alternate example I'm attaching?

Thank you!

Boo, I forgot the attach, :p

Using Facundo's attachment:

D:\>using_subprocess.py

D:\>

Great! So it's fixed, :)