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

Groups > comp.lang.python > #12368 > unrolled thread

killing a script

Back to article view | Back to comp.lang.python

Contents

  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

Page 2 of 2 — ← Prev page 1 [2]

#13114

Cameron Simpson wrote:

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

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.


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#13058

On Sat, 10 Sep 2011 11:25:40 +1000, Steven D'Aprano wrote:

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

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

[toc] | [prev] | [next] | [standalone]

#12378

"Russ P." <russ.paielli@gmail.com> writes:
> Thanks for the suggestion. Yeah, I guess I could do that, but it seems
> that there should be a simpler way to just kill the "whole enchilada."
> Hitting Control-C over and over is a bit like whacking moles.

Hit Ctrl-Z, which stops execution of the subprogram but doesn't kill it.
Then kill both the subprogram and the control program from a terminal
window.

[toc] | [prev] | [next] | [standalone]

#12395

On Sun, 28 Aug 2011 18:15:56 -0700, Russ P. wrote:

> Is there a
> simple way to ensure that the first Control-C will kill the whole darn
> thing, i.e, the top-level script? Thanks.

You might try using subprocess.Popen() or subprocess.call() rather than
os.system().

os.system() calls the platform's system() function. On Unix, this
specifically ignores SIGINT and SIGQUIT for the duration of the call,
ensuring that Ctrl-C and Ctrl-\ only affect the child process and not the
parent.

subprocess.Popen() doesn't perform any implicit signal handling; it's
implemented in Python in terms of os.fork() and os.execvp[e](). It also
has a better interface (i.e. you get to directly control the argument list
passed to the child process, rather than having to construct a shell
command and hope that you got the quoting/escaping correct).

This may not suffice if any of the descendent processes are moved into
their own process group, as signals generated by the tty driver are sent
only to the foreground process group. However, this is unlikely to be an
issue for simple non-interactive programs (e.g. standard Unix "commands").

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.python

csiph-web