[Top][All Lists]

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

Re: process substitution error handling

From: Jason A. Donenfeld
Subject: Re: process substitution error handling
Date: Thu, 6 Aug 2020 14:14:07 +0200

On Thu, Aug 6, 2020 at 1:15 PM Oğuz <oguzismailuysal@gmail.com> wrote:
> 6 Ağustos 2020 Perşembe tarihinde Jason A. Donenfeld <Jason@zx2c4.com> yazdı:
>> 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.
>     set -e o substfail
>     : <(sleep 10; exit 1)
>     foo
> Say that `foo' is a command that takes longer than ten seconds to complete, 
> how would you expect the shell to behave here? Should it interrupt `foo' or 
> wait for its termination and exit then? Or do something else?

It's likely simpler to check after foo, since bash can just ask "are
any of the process substitution processes that I was wait(2)ing on in
exited state with non zero return?", which just involves looking in a
little list titled exited_with_error_process_subst for being non-null.

A more sophisticated implementation could do that asynchronously with
signals and SIGCHLD. In that model, if bash gets sigchld from a
process that exits with failure, it then exits inside the signal
handler there. This actually wouldn't be too hard to do either.


reply via email to

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