[ python-Bugs-602245 ] os.popen() negative error code IOError

[SourceForge.net]

Bugs item #602245, was opened at 2002-08-30 07:25
Message generated for change (Comment added) made by pmoore
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=602245&group_id=5470

Category: Windows
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Delaney (tcdelaney)
Assigned to: Mark Hammond (mhammond)
Summary: os.popen() negative error code IOError

Initial Comment:
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')


----------------------------------------------------------------------

Comment By: Paul Moore (pmoore)
Date: 2004-05-12 09:32

Message:
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... 

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2004-05-12 04:54

Message:
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.

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2004-05-10 00:45

Message:
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?

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2004-05-05 14:18

Message:
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.

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2004-05-05 13:57

Message:
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?

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-30 15:05

Message:
Logged In: YES 
user_id=6380

I suppose this is one for Mark Hammond...

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2002-08-30 13:38

Message:
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.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=602245&group_id=5470