help-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Christof Warlich
Subject: Re: [Help-bash] behavior of -o pipefail
Date: Mon, 29 Oct 2018 20:49:32 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1

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?




reply via email to

[Prev in Thread] Current Thread [Next in Thread]