Re: [Help-bash] too paranoid?

[Stephane Chazelas]

2016-03-21 12:55:52 -0600, 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);

Sorry, maybe I wasn't clear. The system() part is clear, my
question was more about the behaviour of "sh" and the exit
status it should return in that case.

system("cmd") will return the exit status of the child process
(the one that then executes sh and then may eventually execute
"cmd" when not done in a child process) as returned by
waitpid/wait4.

If cmd is killed by signal n (here to simplify and did not
generate a core), should (as in what would be the "correct"
thing?) system return (128+n) << 8 or n or something else?

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

No, ping is correct. ping relies on CTRL-C to terminate and then
sets the exit status to 0 or non-zero depending on whether the
host replied, as documented. not-a-bug.

-- 
Stephane