Posted March 08, 2017
Just playing around with system calls in Python and sometimes I get some interesting error messages. Note that these examples assume a POSIX-like system (like Linux or Mac OS; these examples might not work on Windows).
Also, while these examples are in Python, one can, of course, get similar results by writing C code that does the same thing; Python just has a nicer interface and is much nicer for doing experiments.
Example 1:
Python 3.5.2+ (default, Dec 13 2016, 14:16:35)
[GCC 6.2.1 20161124] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.set_inheritable(0, False)
>>> os.execl('/bin/cat', 'cat')
cat: -: Bad file descriptor
cat: closing standard input: Bad file descriptor
Explanation: I just ran the "cat" program, but with stdin not present; hence, when "cat" tries to read from stdin (which it expects to exist and be open), it gets errors it's not expecting.
Example 2 (you will need to wait a second after the call to signal.alarm():
Python 3.5.2+ (default, Dec 13 2016, 14:16:35)
[GCC 6.2.1 20161124] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import signal
>>> signal.alarm(1)
0
>>> Alarm clock
"Alarm clock"? Isn't that a strange message to appear as an error message?
Well, what happened is that we arranged for a signal to be sent to the process, but we *did not* actually write a signal handler. By default (at least on Linux), the signal terminates the process with a strange-sounding error.
Also, while these examples are in Python, one can, of course, get similar results by writing C code that does the same thing; Python just has a nicer interface and is much nicer for doing experiments.
Example 1:
Python 3.5.2+ (default, Dec 13 2016, 14:16:35)
[GCC 6.2.1 20161124] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.set_inheritable(0, False)
>>> os.execl('/bin/cat', 'cat')
cat: -: Bad file descriptor
cat: closing standard input: Bad file descriptor
Example 2 (you will need to wait a second after the call to signal.alarm():
Python 3.5.2+ (default, Dec 13 2016, 14:16:35)
[GCC 6.2.1 20161124] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import signal
>>> signal.alarm(1)
0
>>> Alarm clock
Well, what happened is that we arranged for a signal to be sent to the process, but we *did not* actually write a signal handler. By default (at least on Linux), the signal terminates the process with a strange-sounding error.
Post edited March 08, 2017 by dtgreene