[Top][All Lists]

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

Re: process substitution error handling

From: Chet Ramey
Subject: Re: process substitution error handling
Date: Thu, 6 Aug 2020 10:30:08 -0400
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.11.0

On 8/6/20 6:05 AM, Jason A. Donenfeld wrote:
> Hi,
> It may be a surprise to some that this code here winds up printing
> "done", always:
> $ cat a.bash
> set -e -o pipefail
> while read -r line; do
>        echo "$line"
> done < <(echo 1; sleep 1; echo 2; sleep 1; false; exit 1)
> sleep 1
> echo done
> $ bash a.bash
> 1
> 2
> done
> The reason for this is that process substitution right now does not
> propagate errors. It's sort of possible to almost make this better
> with `|| kill $$` or some variant, and trap handlers, but that's very
> clunky and fraught with its own problems.
> Therefore, I propose a `set -o substfail` option for the upcoming bash
> 5.1, which would cause process substitution to propagate its errors
> upwards, even if done asynchronously.
> Chet - thoughts?

I don't like it, for two reasons:

1. Process substitution is a word expansion, and, with one exception, word
   expansions don't contribute to a command's exit status and
   consequently the behavior of errexit, and this proposal isn't compelling
   enough to change that even with a new option; and

2. Process substitution is asynchronous. I can't think of how spontaneously
   changing $? (and possibly exiting) at some random point in a script when
   the shell reaps a process substitution will make scripts more reliable.

``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/

reply via email to

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