On 10Sep2011 11:25, Steven D'Aprano <steve+comp.lang.pyt...@pearwood.info> 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 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, -- Cameron Simpson <c...@zip.com.au> DoD#743 http://www.cskk.ezoshosting.com/cs/ But pessimism IS realism! - D.L.Bahr -- http://mail.python.org/mailman/listinfo/python-list
