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

[Tadeus Prastowo]

On Mon, Oct 29, 2018 at 8:49 PM, Christof Warlich <address@hidden> wrote:
> 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.

What about the case where grep as the last in the pipe is invoked with
switch `-m1', which may cause an error coming from some process
earlier in the pipeline?

> 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?

--
Best regards,
Tadeus