Re: why does close() fail miserably on popen with exit code -1 ?!
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). -- http://mail.python.org/mailman/listinfo/python-list
Re: why does close() fail miserably on popen with exit code -1 ?!
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 "", 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 ***
--
http://mail.python.org/mailman/listinfo/python-list
Re: why does close() fail miserably on popen with exit code -1 ?!
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: why does close() fail miserably on popen with exit code -1 ?!
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? -- http://mail.python.org/mailman/listinfo/python-list
Re: why does close() fail miserably on popen with exit code -1 ?!
"Atanas Banov" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: why does close() fail miserably on popen with exit code -1 ?!
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 "", 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;
}
--
http://mail.python.org/mailman/listinfo/python-list
Re: why does close() fail miserably on popen with exit code -1 ?!
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
--
http://mail.python.org/mailman/listinfo/python-list
Re: why does close() fail miserably on popen with exit code -1 ?!
Quoth "Atanas Banov" <[EMAIL PROTECTED]>:
| 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 "", line 1, in ?
| IOError: (0, 'Error')
| >>> print popen('exit -2').close()
| -2
|
| has anyone have idea why is that?
I have no idea about Microsoft Windows, and I doubt that you could
reproduce this on UNIX, but neither does this look like a valid
UNIX program. Exit codes are integer values in the range [0..255],
so there are no negative numbers (which is what I think you intended),
nor are there strings (which is what '-1' would have been with the
classic UNIX shell.)
So I will leave it to someone else to wrestle with the Microsoft
problem, but I just wanted to point out that it isn't something you
could expect to work anywhere else.
Donn Cave, [EMAIL PROTECTED]
--
http://mail.python.org/mailman/listinfo/python-list
Re: 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.
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
--
http://mail.python.org/mailman/listinfo/python-list
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 "", line 1, in ?
IOError: (0, 'Error')
>>> print popen('exit -2').close()
-2
has anyone have idea why is that?
- nas
--
http://mail.python.org/mailman/listinfo/python-list
