os.system error returns

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

os.system error returns

Grawburg
I have a piece of code written for a Raspberry Pi with no explanation for two of the lines -- and I can't find an explanation I understand.

Here are the lines:
if os.system('modprobe --first-time -q w1_gpio') ==0

if os.system('modprobe -q w1_gpio') == 256:



I know what the 'modprobe...' is, it's the 0 and the 256 I don't get. Where do these numbers come from?
I recognize they're some kind of error returns, but don't know what they mean.


Thanks,
Brian Grawburg





Reply | Threaded
Open this post in threaded view
|

os.system error returns

Ben Finney-10
Grawburg <grawburg at myglnc.com> writes:

> if os.system('modprobe --first-time -q w1_gpio') ==0
>
> if os.system('modprobe -q w1_gpio') == 256:
>
> I know what the 'modprobe...' is, it's the 0 and the 256 I don't get.
> Where do these numbers come from?

They are integer literals, they come from the source code.

The statements are comparing those integers to the return value from
?os.system?. The return value from ?os.system? is whatever was the child
process sets as its exit status.

> I recognize they're some kind of error returns, but don't know what
> they mean.

That's not up to Python, it's entirely set by the external program.

There is no standardisation of exit status values between different
programs. The best one can say is ?exit status 0 means success?.
Anything further is specific to particular programs and is not
universal.

You'll need to see the documentation for ?modprobe(1)? to find out what
its different exit status values mean.

--
 \       ?The Vatican is not a state.? a state must have people. There |
  `\    are no Vaticanians.? No-one gets born in the Vatican except by |
_o__)        an unfortunate accident.? ?Geoffrey Robertson, 2010-09-18 |
Ben Finney


Reply | Threaded
Open this post in threaded view
|

os.system error returns

Peter Otten
In reply to this post by Grawburg
Grawburg wrote:

> I have a piece of code written for a Raspberry Pi with no explanation for
> two of the lines -- and I can't find an explanation I understand.
>
> Here are the lines:
> if os.system('modprobe --first-time -q w1_gpio') ==0
>
> if os.system('modprobe -q w1_gpio') == 256:
>
>
>
> I know what the 'modprobe...' is, it's the 0 and the 256 I don't get.
> Where do these numbers come from? I recognize they're some kind of error
> returns, but don't know what they mean.

By convention a return value of 0 means that the invoked program terminated
normally, non-zero returns indicate an error. For the details you have to
look into the modprobe documentation.

The invoked program is free to return a value in the range 0...255 which
then goes into the upper byte of the return value of os.system(). For
example let's use python instead of modprobe:

>>> os.system("python -c 'exit(42)'")
10752

You don't recognize the 42? Then how about

>>> os.system("python -c 'exit(42)'") >> 8
42

Read

https://docs.python.org/2.7/library/os.html#os.system

for the details.


Reply | Threaded
Open this post in threaded view
|

os.system error returns

Grant Edwards-7
In reply to this post by Grawburg
On 2015-06-12, Ben Finney <ben+python at benfinney.id.au> wrote:

> There is no standardisation of exit status values between different
> programs. The best one can say is ?exit status 0 means success?.
> Anything further is specific to particular programs and is not
> universal.
>
> You'll need to see the documentation for ?modprobe(1)? to find out what
> its different exit status values mean.

It's modprobe(8), and all the man page says is that it returns
non-zero if you try to remove or insert a module it can't find.

Explicitly checking for an os.system() return value of 1<<8 seems like
a pretty bad idea to me, since there's nothing in the modprobe docs
that gurantees it will return 1 under some particular conditions.

--
Grant Edwards               grant.b.edwards        Yow! YOU PICKED KARL
                                  at               MALDEN'S NOSE!!
                              gmail.com            

Reply | Threaded
Open this post in threaded view
|

os.system error returns

Ian Kelly-2
In reply to this post by Grawburg
On Jun 12, 2015 7:21 AM, "Grawburg" <grawburg at myglnc.com> wrote:
>
> I have a piece of code written for a Raspberry Pi with no explanation for
two of the lines -- and I can't find an explanation I understand.
>
> Here are the lines:
> if os.system('modprobe --first-time -q w1_gpio') ==0
>
> if os.system('modprobe -q w1_gpio') == 256:
>
>
>
> I know what the 'modprobe...' is, it's the 0 and the 256 I don't get.
Where do these numbers come from?
> I recognize they're some kind of error returns, but don't know what they
mean.

Exit code 0 traditionally means success. The exit status is two bytes, with
the low-order byte normally containing the exit code and the high-order
byte containing the signal that caused the program to exit. So 256 would
appear to mean that modprobe exited due to SIGHUP, although that seems an
odd thing to test for here so I may be wrong.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20150612/5420715f/attachment.html>

Reply | Threaded
Open this post in threaded view
|

os.system error returns

Ian Kelly-2
On Jun 12, 2015 7:54 AM, "Ian Kelly" <ian.g.kelly at gmail.com> wrote:
>
> On Jun 12, 2015 7:21 AM, "Grawburg" <grawburg at myglnc.com> wrote:
> >
> > I have a piece of code written for a Raspberry Pi with no explanation
for two of the lines -- and I can't find an explanation I understand.
> >
> > Here are the lines:
> > if os.system('modprobe --first-time -q w1_gpio') ==0
> >
> > if os.system('modprobe -q w1_gpio') == 256:
> >
> >
> >
> > I know what the 'modprobe...' is, it's the 0 and the 256 I don't get.
Where do these numbers come from?
> > I recognize they're some kind of error returns, but don't know what
they mean.
>
> Exit code 0 traditionally means success. The exit status is two bytes,
with the low-order byte normally containing the exit code and the
high-order byte containing the signal that caused the program to exit. So
256 would appear to mean that modprobe exited due to SIGHUP, although that
seems an odd thing to test for here so I may be wrong.

Per the last two posters I have it backward, which explains my confusion.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20150612/7968e95f/attachment.html>

Reply | Threaded
Open this post in threaded view
|

os.system error returns

random832@fastmail.us
In reply to this post by Ian Kelly-2
On Fri, Jun 12, 2015, at 09:54, Ian Kelly wrote:

> Exit code 0 traditionally means success. The exit status is two bytes,
> with
> the low-order byte normally containing the exit code and the high-order
> byte containing the signal that caused the program to exit.

That's backwards. The signal (or 0 for a normal exit, or 0177 if the
process is stopped) is in the low seven bits of the low-order byte, the
core dump flag is in the high bit of the low-order byte and the exit
status or the stop signal is in the high-order byte.

I think you're confused because the _shell_ puts the exit status, or the
signal plus 128, in the $? variable, and many languages (but not python)
follow suit.

Reply | Threaded
Open this post in threaded view
|

os.system error returns

random832@fastmail.us
For completeness I will note that Windows is completely different. The
plain exit status (1 for typical command failures) appears in the
os.system result rather than a wait-encoded value. And, incidentally, an
MSVC program which calls abort() will return an exit status of 3. A
process that terminates another process with TerminateProcess can set
that process's exit status to an arbitrary 32-bit value. The MSVC exit
function limits the value to one byte, but the raw ExitProcess system
call supports any 32-bit value.

And, just for fun, two versions of "cat" on my system (one supplied with
Git, and one from gnuwin32) return 0x10200 and 0xC000013A respectively
when terminated by Ctrl-C. I think the first is some effort at an
alternate encoding that's compatible with plain exit statuses in the
low-order byte, and the second is the value of STATUS_CONTROL_C_EXIT (an
HRESULT).

I found some information on google suggesting that some unix-alike
layers use an exit status of 0xC00002NN to represent signals (with, once
again, plain exit status being a value of 0x00NN).

All of these values are available as the returned value from os.system.