please help me understand os.system() result
Roman Suzi
Under Linux I have very strange results for exit status info:
>>> os.system("exit 7")
1792
>>> os.system("python -c 'import sys;sys.exit(1)'")
256
>>> os.system("python -c 'import sys;sys.exit(2)'")
512
True for my RH 7.3 and 6.2, for Pythons 1.5.2, 2.1, 2.2.2.
Any ideas?
Sincerely yours, Roman A.Suzi
--
- Petrozavodsk - Karelia - Russia - mailto:r...@onego.ru -
Keisuke URAGO
On Tue, 20 May 2003 15:17:17 +0400 (MSD)
Roman Suzi <r...@onego.ru> wrote:
>
> Under Linux I have very strange results for exit status info:
>
> >>> os.system("exit 7")
> 1792
> >>> os.system("python -c 'import sys;sys.exit(1)'")
> 256
> >>> os.system("python -c 'import sys;sys.exit(2)'")
> 512
>
> True for my RH 7.3 and 6.2, for Pythons 1.5.2, 2.1, 2.2.2.
>
> Any ideas?
You should shift 8bits like this.
>>> os.system("exit 7") >> 8
7
>>> os.system("python -c 'import sys;sys.exit(1)'") >> 8
1
>>> os.system("python -c 'import sys;sys.exit(2)'") >> 8
2
Cheers,
==
Keisuke URAGO <brav...@Mresourcez.org> http://open.resourcez.org/
Key fingerprint = B64B 4D6B 45A7 74FB 5537 A57A 6027 F69D 0188 3935
Eric Brunel
> Under Linux I have very strange results for exit status info:
>
>
>>>>os.system("exit 7")
>>>
> 1792
>
>>>>os.system("python -c 'import sys;sys.exit(1)'")
>>>
> 256
>
>>>>os.system("python -c 'import sys;sys.exit(2)'")
>>>
> 512
>
> True for my RH 7.3 and 6.2, for Pythons 1.5.2, 2.1, 2.2.2.
>
> Any ideas?
>
> Sincerely yours, Roman A.Suzi
According to the library reference (
http://www.python.org/doc/current/lib/os-process.html#l2h-1226 ):
"The return value [of os.system] is the exit status of the process encoded in
the format specified for wait(), except on Windows 95 and 98, where it is always 0."
So let's go two paragraphs further for the doc of the wait function:
"[...] return a tuple containing its pid and exit status indication: a 16-bit
number, whose low byte is the signal number that killed the process, and whose
high byte is the exit status (if the signal number is zero); the high bit of the
low byte is set if a core file was produced."
So it enables you to know if the command you ran through system exited normaly
(status % 256 == 0); if so, its exit code (status / 256); if not, the killing
signal (status % 256) and if a core file was produced (status / 256 == 1).
Please note that wait, system and the like have quite a tendency to return None
if the command ran to completion without problem, so you're unlikely to get 0 as
a result.
HTH
--
- Eric Brunel <eric....@pragmadev.com> -
PragmaDev : Real Time Software Development Tools - http://www.pragmadev.com
Duncan Booth
news:bad975$ju1$1...@news-reader12.wanadoo.fr:
> According to the library reference (
> http://www.python.org/doc/current/lib/os-process.html#l2h-1226 ):
>
> "The return value [of os.system] is the exit status of the process
> encoded in the format specified for wait(), except on Windows 95 and
> 98, where it is always 0."
>
> So let's go two paragraphs further for the doc of the wait function:
>
> "[...] return a tuple containing its pid and exit status indication: a
> 16-bit number, whose low byte is the signal number that killed the
> process, and whose high byte is the exit status (if the signal number
> is zero); the high bit of the low byte is set if a core file was
> produced."
>
It looks to me as though the documentation is slightly broken at least on
Windows systems. It says the return value is in the format specified for
wait, but wait is not implemented on Windows systems. It also says that the
return value is system dependant (which is true). The line saying it is the
same as for wait should qualify that as only being true on Unix systems. On
Windows 2k (and I presume NT and XP) the exit code is returned directly.
>>> os.system('''python -c "import sys; sys.exit(23)"''')
23
--
Duncan Booth dun...@rcp.co.uk
int month(char *p){return(124864/((p[0]+p[1]-p[2]&0x1f)+1)%12)["\5\x8\3"
"\6\7\xb\1\x9\xa\2\0\4"];} // Who said my code was obscure?
anandpillai
On windows os.system() returns zero if successful always
and nonzero othewise.
The documentation of this function says,
<quote>
Note that POSIX does not specify the returne value of the C system()
function, so the return value of the python function is system
dependent.
</quote>
Linux is a POSIX system so you need not be surprised
at these return values as long as they are not less than
zero.
Anand Pillai
--
"The Python Guy"
Posted via http://dbforums.com
Erik Max Francis
> It looks to me as though the documentation is slightly broken at least
> on
> Windows systems. It says the return value is in the format specified
> for
> wait, but wait is not implemented on Windows systems.
No, the documentation explicitly states that it returns the value
returned by wait, except on Windows "where it is always 0."
--
Erik Max Francis && m...@alcyone.com && http://www.alcyone.com/max/
__ San Jose, CA, USA && 37 20 N 121 53 W && &tSftDotIotE
/ \ A good indignation brings out all one's powers.
\__/ Ralph Waldo Emerson
Erik Max Francis
> According to the library reference (
> http://www.python.org/doc/current/lib/os-process.html#l2h-1226 ): ...
Note that the the return values of os.system and os.wait are just the
same values as their POSIX counterparts, so this is not peculiar to
Python.
> Please note that wait, system and the like have quite a tendency to
> return None
> if the command ran to completion without problem, so you're unlikely
> to get 0 as
> a result.
I'm not sure what this means; under what circumstances does it return
None? Doing so would violate the specification as laid out in the
documentation.
Donn Cave
...
| It looks to me as though the documentation is slightly broken at least on
| Windows systems. It says the return value is in the format specified for
| wait, but wait is not implemented on Windows systems. It also says that the
| return value is system dependant (which is true). The line saying it is the
| same as for wait should qualify that as only being true on Unix systems. On
| Windows 2k (and I presume NT and XP) the exit code is returned directly.
|
| >>> os.system('''python -c "import sys; sys.exit(23)"''')
| 23
As it is on BeOS, if we're keeping score. I assume Windows Python's
os.WEXITSTATUS(exit_status) accounts for this difference, so you can
write ``portable'' code this way.
Donn Cave, do...@u.washington.edu
Tim Peters
>> It looks to me as though the documentation is slightly broken at least
>> on Windows systems. It says the return value is in the format specified
>> for wait, but wait is not implemented on Windows systems.
[Erik Max Francis]
> No, the documentation explicitly states that it returns the value
> returned by wait, except on Windows "where it is always 0."
No <wink>, the docs say "except on Windows 95 and 98, where it is always 0".
That's not so on WinNT, Win2K or WinXP. The docs definitely need
clarification.
Donn Cave
|> Please note that wait, system and the like have quite a tendency to
|> return None
|> if the command ran to completion without problem, so you're unlikely
|> to get 0 as
|> a result.
|
| I'm not sure what this means; under what circumstances does it return
| None? Doing so would violate the specification as laid out in the
| documentation.
He was probably actually thinking of popen() --
fp = os.popen('echo hi; exit 7', 'r')
>>> t = fp.read()
>>> x = fp.close()
>>> print x
1792
fp = os.popen('echo hi; exit 0', 'r')
>>> t = fp.read()
>>> x = fp.close()
>>> print x
None
Can't think of any good reason for this, right off hand, but it
has always been thus.
Donn Cave, do...@u.washington.edu
Erik Max Francis
> Can't think of any good reason for this, right off hand, but it
> has always been thus.
But since it's documented behavior (6.1.2), it's quite all right.
--
Erik Max Francis && m...@alcyone.com && http://www.alcyone.com/max/
__ San Jose, CA, USA && 37 20 N 121 53 W && &tSftDotIotE
/ \ We are circumstances of our birth.
\__/ Sade Adu
Donn Cave
|
| > Can't think of any good reason for this, right off hand, but it
| > has always been thus.
|
| But since it's documented behavior (6.1.2), it's quite all right.
Gratuitous inconsistencies are quite all right as long as they're
in the documentation? Whatever. It's late to change it, anyway,
but it would be nice if os.WEXITSTATUS could handle the return from
popen().close() (and return integer [0..127], of course.)
Donn Cave, do...@u.washington.edu
Roman Suzi
> You should shift 8bits like this.
>
> >>> os.system("exit 7") >> 8
> 7
> >>> os.system("python -c 'import sys;sys.exit(1)'") >> 8
> 1
> >>> os.system("python -c 'import sys;sys.exit(2)'") >> 8
> 2
Thank you, I already guessed it.
However, it's strange that os.system() behaves like this on Linux and the
other way on WinNT/2000. (This is in the docs - so ok)
Duncan Booth
news:3ECA4B23...@alcyone.com:
> Duncan Booth wrote:
>
>> It looks to me as though the documentation is slightly broken at least
>> on
>> Windows systems. It says the return value is in the format specified
>> for
>> wait, but wait is not implemented on Windows systems.
>
> No, the documentation explicitly states that it returns the value
> returned by wait, except on Windows "where it is always 0."
No, it says that on Windows 95 and 98 it is always 0. I don't know the
truth or otherwise of that statement, but on Windows 2000, and I assume
therefore also NT and XP, it returns the exit code.
You even trimmed the example from my post which was cut and pasted on a
Windows 2000 system:
Tim Roberts
>On Tue, 20 May 2003, Keisuke URAGO wrote:
>
>> You should shift 8bits like this.
>>
>> >>> os.system("exit 7") >> 8
>> 7
>> >>> os.system("python -c 'import sys;sys.exit(1)'") >> 8
>> 1
>> >>> os.system("python -c 'import sys;sys.exit(2)'") >> 8
>> 2
>
>Thank you, I already guessed it.
>However, it's strange that os.system() behaves like this on Linux and the
>other way on WinNT/2000. (This is in the docs - so ok)
It's not so strange; os.system is returning exactly what the "system"
standard library function would return. Windows programmers are used to
their way, Unix programmers are used to their way.
For those few programs that need to work on both, it only takes a couple of
lines of code to handle this.
--
- Tim Roberts, ti...@probo.com
Providenza & Boekelheide, Inc.