Re: [Help-bash] too paranoid?

[Stephane Chazelas]

2016-03-19 16:03:20 -0600, 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? 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 \"$?\"")?

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

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

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.

-- 
Stephane