Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #13055

Re: killing a script

Date 2011-09-10 18:49 +1000
From Cameron Simpson <cs@zip.com.au>
Subject Re: killing a script
References <4e6abc95$0$29995$c3e8da3$5496439d@news.astraweb.com>
Newsgroups comp.lang.python
Message-ID <mailman.928.1315644591.27778.python-list@python.org> (permalink)

Show all headers | View raw


On 10Sep2011 11:25, Steven D'Aprano <steve+comp.lang.python@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 <cs@zip.com.au> DoD#743
http://www.cskk.ezoshosting.com/cs/

But pessimism IS realism!       - D.L.Bahr

Back to comp.lang.python | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

killing a script "Russ P." <russ.paielli@gmail.com> - 2011-08-28 18:15 -0700
  Re: killing a script MRAB <python@mrabarnett.plus.com> - 2011-08-29 02:52 +0100
    Re: killing a script "Russ P." <russ.paielli@gmail.com> - 2011-08-28 19:41 -0700
      Re: killing a script Chris Angelico <rosuav@gmail.com> - 2011-08-29 12:51 +1000
        Re: killing a script "Russ P." <russ.paielli@gmail.com> - 2011-08-28 20:08 -0700
          Re: killing a script Chris Rebert <clp2@rebertia.com> - 2011-08-28 20:16 -0700
            Re: killing a script "Russ P." <russ.paielli@gmail.com> - 2011-08-28 20:22 -0700
            Re: killing a script "Russ P." <russ.paielli@gmail.com> - 2011-08-29 14:26 -0700
          Re: killing a script Thomas Jollans <t@jollybox.de> - 2011-08-29 09:49 +0200
          Re: killing a script Arnaud Delobelle <arnodel@gmail.com> - 2011-08-29 23:53 +0100
            Re: killing a script Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-08-30 14:13 +1000
              Re: killing a script Hans Mulder <hansmu@xs4all.nl> - 2011-08-30 12:40 +0200
              Re: killing a script Cameron Simpson <cs@zip.com.au> - 2011-09-09 10:03 +1000
                Re: killing a script Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-09-09 19:07 +1000
                Re: killing a script Hans Mulder <hansmu@xs4all.nl> - 2011-09-09 12:13 +0200
                Re: killing a script Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-09-09 22:16 +1000
                Re: killing a script Cameron Simpson <cs@zip.com.au> - 2011-09-10 08:29 +1000
                Re: killing a script Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-09-10 11:25 +1000
                Re: killing a script Chris Angelico <rosuav@gmail.com> - 2011-09-10 11:37 +1000
                Re: killing a script Cameron Simpson <cs@zip.com.au> - 2011-09-10 18:49 +1000
                Re: killing a script Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-09-11 15:08 +1000
                Re: killing a script Nobody <nobody@nowhere.com> - 2011-09-10 10:47 +0100
      Re: killing a script Paul Rubin <no.email@nospam.invalid> - 2011-08-28 19:53 -0700
  Re: killing a script Nobody <nobody@nowhere.com> - 2011-08-29 07:52 +0100

csiph-web