killing a script

Cameron Simpson cs at
Sat Sep 10 10:49:38 CEST 2011

On 10Sep2011 11:25, Steven D'Aprano <steve+comp.lang.python at> wrote:
| Cameron Simpson wrote:
| > My copy of the 2.7 docs says:
| >   This is implemented by calling the Standard C function system(), and
| >   has the same limitations.
| > and sure enough, "man 3 system" says:
| I don't consider having to look up documentation for a function in a
| completely different language (in this case, C) as "documented behaviour of
| os.system". 

You're kidding, surely? A wrapper function for a system supplied function
should recite everything about the wrapped function's behaviour (including
the system dependent stuff) in the wrapper doco?

| Does the C standard define the behaviour of system(), or is that
| implementation dependent?

The standard specifies the core behaviour - the behaviour guarrenteed to
be present everywhere. Plenty of stuff has platform dependent minor
nuances. As long as portable code relies only on the standard behaviour
everybody wins.

| It sounds to me that the Python developers are
| implicitly refusing responsibility for the detailed behaviour of os.system
| by noting that it depends on the C function.

Of course they are, and they are right to do so. But noting that it
calls the standard function does guarrentee various things about what it

| What do Jython, PyPy and
| IronPython do?
| Perhaps the docs for os.system should explicitly note that the behaviour is
| implementation dependent, rather than just hint at it. Either that or
| explicitly state what os.system does.

I find it hard to understand how anyone can read this text:

  This is implemented by calling the Standard C function system(), and
  has the same limitations

and not imagine it to be dependent on the specification for system().

| > Continuing with the Python docs for os.system: 
| > 
| >   On Unix, the return value is the exit status of the process encoded in
| >   the format specified for wait().
| > 
| > and it is easy to inspect that value for "the subprocess died from a
| > signal". Not inspecting the exit status correctly will always be an
| > opportunity for incorrect app behaviour.
| Except that the subprocess can catch the KeyboardInterrupt before exiting,

This is very true, though such programs usually have a special reason to
do so - the default aborting behaviour is often sufficient.

| and there's no guarantee that it will return an appropriate error code.

Of course. However, the subprocess should still exit with a nonzero exit
status (unless it it written badly). If the caller considers success of
the called program to be important, it should probably be aborting if
the returned value is nonzero anyway.

But yeah, people should probably be reaching for subprocess if they want
to notice SIGINT specially.

Cameron Simpson <cs at> DoD#743

But pessimism IS realism!       - D.L.Bahr

More information about the Python-list mailing list