Re: the zen of SIGPIPE

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Tue, 8 Jan 2013 23:08:20 +0000 (UTC)
    From:        christos%astron.com@localhost (Christos Zoulas)
    Message-ID:  <kci8t4$o82$1%ger.gmane.org@localhost>

  | It is more complicated than that.

Actually, it isn't.  The suggestion was that xargs should ignore
SIGINT (while waiting on a child anyway) - for that, it really
doesn't matter whether or not xargs would ever see the SIGINT that it
is ignoring (whether the signal goes to some other process group,
or whatever) - at worst, if it is running such a program, then
ignoring the SIGINT is a little wasted time.

There's a reasonable argument that any process waiting on a foreground
process should ignore terminal generated signals, leaving those to
be processed by the foreground process that it is waiting on (so the
signals can be used for other than just "exit").  Alternatively, perhaps
processes creating foreground children should always create new process
groups for them, so tty signals only go to the current foreground
process.

If that isn't done, then if the child process decides to catch or
ignore a signal, and continue running, but its parent has exited
on the signal, you get the situation where both the child, and the
grandparent, process can be fighting over the terminal.  Where the
grandparent is a (modern) shell, which it often is in these cases,
then its manipulation of process groups usually makes this easy to
recover from (the child ends up getting one of the job control
signals, which, without a parent, usually causes its death).

But if the grandparent is just another boring process, you can get
two processes reading the terminal at the same time, which can sometimes
be difficult to escape from, at least without the aid of a parallel
connection to use to kill things.

On the other hand ...

  | ... , the simplest thing xargs can do is nothing (which is what it
  | is currently doing). 

that's certainly true, and absent actual bug reports of problems in
non-contrived situations, is most probably the right approach.

Of course, none of this has anything at all to do with the original
reported problem, which is whether or not xargs (and some other programs
like it) should go to the trouble of checking the exit status of the
prigrams they run, and only printing an error in such a situation if that
is what the shell would do (that is, if the child exits with SIGPIPE,
or SIGINT, then be quiet, if it exists with some other signal, then
report it).

Personally I doubt that the issue is serious enough to bother.

kre