killing a script

[Steven D'Aprano]

Cameron Simpson wrote:

> On 09Sep2011 22:16, Steven D'Aprano <steve+comp.lang.python at pearwood.info>
> wrote:
> | Hans Mulder wrote:
> | > On 9/09/11 11:07:24, Steven D'Aprano wrote:
> | >> Sure enough, I now have to hit Ctrl-C repeatedly, once per invocation
> | >> of script.py. While script.py is running, it receives the Ctrl-C, the
> | >> calling process does not.
> | > 
> | > You misinterpret what you are seeing: the calling process *does*
> | > receive the ctrl-C, it just chooses to ignore it.
> | >
> | > This is documented behaviour of os.system.
> | 
> | Documented where? Neither the on-line documentation nor the function
> | docstring mentions anything about it that I can see:
> | 
> | http://docs.python.org/py3k/library/os.html#os.system
> 
> 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". 

Does the C standard define the behaviour of system(), or is that
implementation dependent? 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. 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.


> os.system() is very convenient for simple stuff, but one size does not
> fit all. 

I never said it does. Back in my first comment on this thread, I said

"Possibly using the subprocess module may help."


> 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,
and there's no guarantee that it will return an appropriate error code.

You're right though, os.system is good for simple stuff and not much more.


-- 
Steven