2015-05-29 22:47:05 -0500, Rob Landley:
> On Fri, May 29, 2015 at 5:08 PM, Stephane Chazelas
> > 2015-05-29 22:45:31 +0100, Pádraig Brady:
> >> Well another reason for having SIGPIPE over write returning EPIPE,
> >> is that one can distinguish the signal exit status (WIFSIGNALED).
> >> The shell should handle this specially and not exit 141 in this case.
> >> (as it does normally with a straight: seq 10000 | head && echo ok
> > [...]
> > Alright, sorry I thought the discussion was about the pipefail
> > implementation treating "dying of sigpipe" as a non-error
> > condition, as opposed to utilities returning 0 when failing to
> > write on a broken pipe.
> > I don't like that idea.
> > Failing to write should be an error condition.
> Given that "yes" produces endless output, you're saying it should
> never be possible for it to exit with a non-error condition?
Well, yes, "yes" can never manager to write all its output, it
will either die of a signal (SIGPIPE, SIXCPU, SIGINT...) or a
write error (disk full, broken pipe, file too big, quota
The point is that there's generally little point *checking* its
exit status (except maybe to discriminate between the different
error conditions), not that its exit status should be changed to
always mean success instead of failure.
If we want pipefail to not be affected by SIGPIPE, then the
burden of implementing that would be on the pipefail feature in
the shell, not in the utilities to work around the shell's
pipefail implementation defficiency.
If you wan't to ignore pipefail for a specific pipeline
component, then, you could do:
set -o pipefail
(trap - PIPE; yes || [ "$(kill -l -- "$?") = PIPE ]) | head |
Now, that's where the issue I just raised with builtins becomes
a real problem, since that wouldn't work for builtins.