Re: [Help-bash] too paranoid?

[Bob Proulx]

Stephane Chazelas wrote:
> Bob Proulx:
> > Because I think it is certainly possible for software to operate
> > correctly.
> 
> But who defines "correctly" here.
> 
> What should:
> 
> system("cmd")
> 
> return when cmd dies of signal n?

First I look at 'man 3 system' in order to read the locally installed
system documentation.  Then I go to the online standards documenation.
That is who defines what "correctly" means with respect to system(3).

  http://pubs.opengroup.org/onlinepubs/009695399/functions/system.html

> Some sh implementation will run "cmd" in the same process, some in a
> child. Should the latter kill themselves with the same signal like
> ksh93?  If yes, should they also do it in system("cmd; exit"), or
> system("cmd; exit \"$?\"")?

The correct behavior is as defined:

  The environment of the executed command shall be as if a child
  process were created using fork(), and the child process invoked the
  sh utility using execl() as follows:

  execl(<shell path>, "sh", "-c", command, (char *)0);

> Is it correct for:
> 
> bash -c 'ping -c1 1.1.1.1; echo foo'
> 
> to output "foo" after you've pressed CTRL-C (or in other words
> for your CTRL-C to not interrupt a script when that script
> happens to be running a command that intercepts SIGINT)?

Ping!  One of the most well known of the buggy interrupt handling
programs in wide use.  To answer your question, no, it is incorrect.
Ping is quite infamous for this problem.  Another infamous command is
rsync, which at least documents the behavior.

  EXIT VALUES
       0      Success
       ...
       20     Received SIGUSR1 or SIGINT

> What I mean is that what's correct is still up for discussion.
> Not everyone agrees that the bash behaviour is best there.

This is the Internet and you are expecting everyone to be in
agreement?  It isn't concensus that binds the Internet together.  It
is the flamewar.  Concensus is a very rare thing.  But we do have the
standards and those are what keep things from diverging into
debilitating differences.

> In that context, accepting that a 128+n<<8 exit status also
> means a death by signal n is potentially more useful than making
> sure you kill yourself with the same signal number in your
> handler for that signal (again, except for SIGINT and SIGQUIT
> because of that behaviour of bash and a few other shells).
> I agree it's better to kill yourself here, but it could be
> considered "marginally" better, and maybe not worth it when to
> do it portably, you've got to make your script significantly
> more complex.

Again, here I think we can only agree to disagree.  Sorry.  The only
correct behavior is for the process to send a signal to itself.  This
is easy for the process to program.  It isn't a burden.

Bob