f



why does close() fail miserably on popen with exit code -1 ?!

i ran onto this weirdness today: seems like close() on popen-ed
(pseudo)file fails miserably with exception instead of returning exit
code, when said exit code is -1.

here is the simplest example (under Windows):

>>> print popen('exit 1').close()
1
>>> print popen('exit -1').close()
Traceback (most recent call last):
  File "<interactive input>", line 1, in ?
IOError: (0, 'Error')
>>> print popen('exit -2').close()
-2

has anyone have idea why is that?

- nas

0
enterr (21)
2/20/2006 6:27:16 AM
comp.lang.python 77058 articles. 6 followers. Post Follow

8 Replies
492 Views

Similar Articles

[PageSpeed] 35

Atanas Banov:
>i ran onto this weirdness today: seems like close() on popen-ed
>(pseudo)file fails miserably with exception instead of returning exit
>code, when said exit code is -1.

Not here.

Python 2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310 32 bit (Intel)]
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> print os.popen('exit 1').close()
1

-- 
Ren´┐Ż Pijlman
0
2/20/2006 11:04:46 AM
my gripe is about exit with MINUS ONE, not +1. see my post again.

yes, i know one cannot return -1 in unix (since returned value is
exitcode % 256 * 256), and no, i am not interested in unix behavior.

Rene Pijlman wrote:
> Atanas Banov:
> >i ran onto this weirdness today: seems like close() on popen-ed
> >(pseudo)file fails miserably with exception instead of returning exit
> >code, when said exit code is -1.
>
> Not here.
>
> Python 2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310 32 bit (Intel)]
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import os
> >>> print os.popen('exit 1').close()
> 1

0
enterr (21)
2/20/2006 7:50:47 PM
Atanas Banov wrote:
> i ran onto this weirdness today: seems like close() on popen-ed
> (pseudo)file fails miserably with exception instead of returning exit
> code, when said exit code is -1.
> 
> here is the simplest example (under Windows):
> 
> 
>>>>print popen('exit 1').close()
> 
> 1
> 
>>>>print popen('exit -1').close()
> 
> Traceback (most recent call last):
>   File "<interactive input>", line 1, in ?
> IOError: (0, 'Error')
> 
>>>>print popen('exit -2').close()
> 
> -2
> 
> has anyone have idea why is that?

_PyPclose returns the exit status of the popened process (the popenee?), 
or -1 on error.  Of course, if the status is supposed to be -1, there's 
some confusion.

In the snippet of code below (from Modules/posixmodule.c), result has 
been initialized to the output of fclose, which in your case is 0.  The 
comment is particularly handy.

	if (result != EOF &&
	    waitpid(pipe_pid, &exit_code, 0) == pipe_pid)
	{
		/* extract exit status */
		if (WIFEXITED(exit_code))
		{
			result = WEXITSTATUS(exit_code);
		}
		else
		{
			errno = EPIPE;
			result = -1;
		}
	}
	else
	{
		/* Indicate failure - this will cause the file object
		 * to raise an I/O error and translate the last
		 * error code from errno.  We do have a problem with
		 * last errors that overlap the normal errno table,
		 * but that's a consistent problem with the file object.
		 */
		result = -1;
	}
0
jeff34 (1597)
2/20/2006 9:26:10 PM
"Atanas Banov" <enterr@gmail.com> wrote in message 
news:1140465047.381586.224530@g47g2000cwa.googlegroups.com...
>
> my gripe is about exit with MINUS ONE, not +1. see my post again.

FWIW, I reproduced the error message for -1 (and the no error for -2, -3) 
in the Idle Python Shell uder Win XP home.

tjr



0
tjreedy (5460)
2/20/2006 10:04:25 PM
Jeffrey Schwab wrote:
> _PyPclose returns the exit status of the popened process (the popenee?),
> or -1 on error.  Of course, if the status is supposed to be -1, there's
> some confusion.

yes, that's what i thought the root of the problem is.

> In the snippet of code below (from Modules/posixmodule.c), result has
> been initialized to the output of fclose, which in your case is 0.  The
> comment is particularly handy.
>
....
> 		/* Indicate failure - this will cause the file object
> 		 * to raise an I/O error and translate the last
> 		 * error code from errno.  We do have a problem with
> 		 * last errors that overlap the normal errno table,
> 		 * but that's a consistent problem with the file object.
> 		 */

the piece you quoted is from the unix #ifdef part, i think. there is
another version of the pypclose for windows below that.

in any event i think such behaviour is a bug - just because in unix
exit codes are limited to 0..255 (and returned multiplied by 256)
doesnt mean other OSes should suffer because of design flow in
_PyPclose, right?

throwing an IOError "no error" doesnt help.

is there a bug database for python where i can check if this was
discussed?

0
enterr (21)
2/21/2006 9:33:36 PM
Atanas Banov wrote:
> Jeffrey Schwab wrote:
> 
>>_PyPclose returns the exit status of the popened process (the popenee?),
>>or -1 on error.  Of course, if the status is supposed to be -1, there's
>>some confusion.
> 
> 
> yes, that's what i thought the root of the problem is.
> 
> 
>>In the snippet of code below (from Modules/posixmodule.c), result has
>>been initialized to the output of fclose, which in your case is 0.  The
>>comment is particularly handy.
>>
> 
> ....
> 
>>		/* Indicate failure - this will cause the file object
>>		 * to raise an I/O error and translate the last
>>		 * error code from errno.  We do have a problem with
>>		 * last errors that overlap the normal errno table,
>>		 * but that's a consistent problem with the file object.
>>		 */
> 
> 
> the piece you quoted is from the unix #ifdef part, i think. there is
> another version of the pypclose for windows below that.
> 
> in any event i think such behaviour is a bug - just because in unix
> exit codes are limited to 0..255 (and returned multiplied by 256)
> doesnt mean other OSes should suffer because of design flow in
> _PyPclose, right?
> 
> throwing an IOError "no error" doesnt help.
> 
> is there a bug database for python where i can check if this was
> discussed?

Yes, there's a bug database linked from python.org; search the main page 
for "Bugs".

Here's the most (seemingly) relevant bug report I can find:
http://sourceforge.net/tracker/index.php?func=detail&aid=602245&group_id=5470&atid=105470
0
jeff34 (1597)
2/22/2006 1:52:04 PM
Still:

phase:toby:~> echo 'exit -1' | bash
phase:toby:~> echo $?
255
phase:toby:~> 


Jeffrey Schwab wrote:
> Atanas Banov wrote:
> 
>> i ran onto this weirdness today: seems like close() on popen-ed
>> (pseudo)file fails miserably with exception instead of returning exit
>> code, when said exit code is -1.
>>
>> here is the simplest example (under Windows):
>>
>>
>>>>> print popen('exit 1').close()
>>
>>
>> 1
>>
>>>>> print popen('exit -1').close()
>>
>>
>> Traceback (most recent call last):
>>   File "<interactive input>", line 1, in ?
>> IOError: (0, 'Error')
>>
>>>>> print popen('exit -2').close()
>>
>>
>> -2
>>
>> has anyone have idea why is that?
> 
> 
> _PyPclose returns the exit status of the popened process (the popenee?), 
> or -1 on error.  Of course, if the status is supposed to be -1, there's 
> some confusion.
> 
> In the snippet of code below (from Modules/posixmodule.c), result has 
> been initialized to the output of fclose, which in your case is 0.  The 
> comment is particularly handy.
> 
>     if (result != EOF &&
>         waitpid(pipe_pid, &exit_code, 0) == pipe_pid)
>     {
>         /* extract exit status */
>         if (WIFEXITED(exit_code))
>         {
>             result = WEXITSTATUS(exit_code);
>         }
>         else
>         {
>             errno = EPIPE;
>             result = -1;
>         }
>     }
>     else
>     {
>         /* Indicate failure - this will cause the file object
>          * to raise an I/O error and translate the last
>          * error code from errno.  We do have a problem with
>          * last errors that overlap the normal errno table,
>          * but that's a consistent problem with the file object.
>          */
>         result = -1;
>     }
*** Free account sponsored by SecureIX.com ***
*** Encrypt your Internet usage with a free VPN account from http://www.SecureIX.com ***
0
toby8882 (35)
3/2/2006 8:29:18 PM
Tobiah wrote:

> phase:toby:~> echo 'exit -1' | bash
> phase:toby:~> echo $?
> 255

http://www.linuxtopia.org/online_books/advanced_bash_scripting_guide/exitcodes.html


Exit Code Number:  255 [1]
Meaning:           Exit status out of range
Example:           exit -1
Comments:          exit takes only integer args in the range 0 - 255


[1] Out of range exit values can result in unexpected exit codes. An 
exit value greater than 255 returns an exit code modulo  256. For 
example, exit 3809 gives an exit code of 225  (3809 % 256 = 225).
0
jeff34 (1597)
3/3/2006 8:58:52 PM
Reply: