Re: EPIPE in standard utils ([issue41])

[Tom Lord]

       > Exit status of non-leading programs in pipelines is a weak
       > spot of shell programming.

       Non-trailing, you mean?

D'oh. (Yes).

      FWIW, it's easy enough to prevent that in the script, by making
      sure the later programs in the pipeline read stdin all the way
      to EOF.  sort "$somefile" |+ sed -n 1p > ,first-one

Thanks -- that's a handy trick in some cases.  It's not too desirable
if the output from the leading programs is potentially much larger
than wat needs to be processed (perhaps even infinite); the trick
applies to `head' (and `tail' and a few others) but isn't a general
solution; it doesn't help with another case:

        foo.sh:

        set -e

        produce_some_output
        important_cleanup_step

if a user runs:

        ./foo.sh | head -1

(Though, yes, there are ugly and inconvenient work arounds for that 
possibility.)

        > Consider that `sort' may get SIGPIPE or EPIPE for two very
        > distinct reasons.  (1) it might get that error because the
        > consumer for its stdout has stopped reading.  This is an
        > ordinary and expected condition and means only that `sort'
        > is free to exit at will.

        That would not be true in a situation where the reading end of the
        pipe is closed as a result of an error, and the error is otherwise not
        reported - or at least, not sufficently reported.  How sure are we
        that that can never happen?

That would represent a bug in the consumer holding the reading end or
the the program that invoked the consumer.

There's always a limit to how much you can guard against other
programs which are buggy -- but the problem is that using the
traditional SIGPIPE behavior, there's a sharp limit on how non-buggy
you can make your scripts because certain non-error conditions are
signaled as if they were errors and thus similar appearing error
conditions are rendered unreportable.

-t