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

[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.

here is the simplest example (under Windows):
Traceback (most recent call last):
-2

has anyone have idea why is that?

- nas

 

[Rene Pijlman]

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.1

 

[Atanas Banov]

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.

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.1

 

[Jeffrey Schwab]

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):



Traceback (most recent call last):


-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;
}

 

[Terry Reedy]

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

 

[Atanas Banov]

_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?

 

[Jeffrey Schwab]

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




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

 

[Tobiah]

Still:

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

_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 ***

 

[Jeffrey Schwab]

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).