killing a script

[Chris Angelico]

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".

The Python docs chain to the C docs. It'd be nice to have a link
somewhere, but that's platform-dependent - the online docs could link
to an online man page, but local docs can't, etc. It's fairly normal
for high level languages to expose a lot of C API functions, with all
the concerns and features given. Not a lot of point bloating the
Python docs with every little detail, imho.

ChrisA

 

[Cameron Simpson]

| 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
does.

| 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.

Cheers,

 

[Nobody]

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".

Well, tough luck. os.system() is a wrapper around the platform's system().
The authors of the Python documentation cannot possibly know what that
function will do on all platforms, even less so once you factor in the
user's ability to replace that function via platform-specific means.

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

The C99 standard says:

7.20.4.5 The system function

Synopsis

[#1]

#include <stdlib.h>
int system(const char *string);

Description

[#2] If string is a null pointer, the system function
determines whether the host environment has a command
processor. If string is not a null pointer, the system
function passes the string pointed to by string to that
command processor to be executed in a manner which the
implementation shall document; this might then cause the
program calling system to behave in a non-conforming manner
or to terminate.

Returns

[#3] If the argument is a null pointer, the system function
returns nonzero only if a command processor is available.
If the argument is not a null pointer, and the system
function does return, it returns an implementation-defined
value.

It doesn't require a platform to even have a command interpreter, let
alone specify its behaviour. On Unix, system() is defined to use /bin/sh,
which ought to be some kind of Bourne shell; but even then, it might be a
minimal shell such as dash or something with many extensions such as bash.
On Windows, it uses the interpreter specified by the COMSPEC environment
variable, or cmd.exe (NT-based) or command.com (DOS-based) if COMSPEC
isn't set (in either case, PATH is used).

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.

Indeed. Which is the correct thing to do. Practically every function in
the os module does likewise.

What do Jython, PyPy and IronPython do?

I don't know, but I would expect them to use libc's system() function,
except for Jython which might use java.lang.Runtime.exec().

 

[Steven D'Aprano]

On 10Sep2011 11:25, Steven D'Aprano <[email protected]>
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?

No, I meant exactly what I said, but I suspect that you misunderstood what I
said. I blame myself for not making myself more clear, sorry.

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?

Heavens no, I certainly don't mean that. That would be silly.

What I mean is that in the context of discussing Python library
functions, "documented behaviour" refers to what the Python docs state,
namely the function docstring and the docs at http://docs.python.org/ (or
the 3.x version). Third-party documentation doesn't count: not blogs,
not "some guy sent me an email", and not documentation for other tools
either.

So if you describe a feature of os.system as "documented", I'm going to
understand that as *Python* documentation. Hence my question about where it
is documented. If we're discussing external documentation, we should say so
up front: not all Python users are using CPython, and not all Python coders
know C and have access to the Linux man pages.