Re: [Help-bash] behavior of -o pipefail

[Christof Warlich]

Am 29.10.2018 um 19:56 schrieb Chet Ramey:

> On 10/29/18 2:37 PM, Christof Warlich wrote:
> > Am 29.10.2018 um 19:17 schrieb Chet Ramey:
> > > My bad, I took another look at your message. The reason that pipefail
> > > makes the rightmost non-zero exit status the status of the pipeline is
> > > also historical. It's what ksh93 did, and therefore what the folks
> > > involved in a discussion about multiple implementations of pipefail
> > > converged on. This happened back in mid-2001, as part of a series of
> > > messages about features to propose to Posix for standardization.
> > Ok. But can we agree that this converged decision (to return the last
> > instead of the first non-zero exit status) was rather unfortunate (for the
> > very reason that I pointed out before)?
> I don't exactly buy that. It's just as likely that an early stage in a
> pipeline exits due to a write error (or SIGPIPE) as the result of a
> fatal error in a subsequent pipeline stage. We had to make a choice, and
> we went with existing practice.

Good point, returning the first or the last error wouldn't matter for
cases where one of the stages breaks the pipe.

But what about filters like grep that are designed to return a status
depending of the data they saw? I would expect that (such) a
well-designed filter would usually not break the pipe, because it would
only exit (with the desired exit status) after seeing EOF.

With piplines being made up of such well-behaving filters, it would
still be beneficial to see the first error instead of the last one. Can
we agree with that?