Re: the zen of SIGPIPE

["Roland C. Dowdeswell" <elric%imrryr.org@localhost>]

On Tue, Jan 08, 2013 at 03:16:01AM -0500, Mouse wrote:
>

> > As for signals, well, it probably makes sense to also propagate
> > SIGINT this way.
> 
> I'm not so sure.
> 
> If SIGINT is tty-generated, it will hit the whole process group
> already.  If that hits xargs, there's no need to push it up; if it
> doesn't, there's probably a reason and it arguably shouldn't.
> 
> Similar remarks apply to other tty-generated signals.
> 
> Non-tty-generated instances of signals which are normally
> tty-generated, like SIGINT...I'm not sure.  I'm tempted to say that
> they're rare enough there's no point in taking any particular measures
> for them.
> 
> SIGSTOP, I'm inclined to agree.
> 
> I do think there should be flags to control all this.

SIGINT is a very interesting case.  Consider:

$ cat igsigint.c 
#include <signal.h>

int
main(int argc, char **argv)
{

        signal(SIGINT, SIG_IGN);
        sleep(100);
}
$ cc -o igsigint igsigint.c
$ echo foo | xargs ./igsigint
^C
$ ps x | grep igsigint
16828 ttyq0  O+    0:00.00 grep igsigint 
29050 ttyq0  S     0:00.00 ./igsigint foo 

So, in this case xargs terminates but its child is still running
as it ignores the signal.  If we run ./igsigint in the shell, ^C
does not interrupt it as the shell ignores SIGINT and rather relies
on the exit status of ./igsigint to determine if a ^C was delivered
(if job control is on, at least.)

So, there might be an argument that xargs should ignore SIGINT,
check the exit status of its children and if they received a SIGINT,
then set the signal handler for SIGINT back to default and raise
a SIGINT.  This may make the behaviour a little more consistent
for interactive use.

--
    Roland Dowdeswell                      http://Imrryr.ORG/~elric/