Re: [RFC] Logically composable variant of errexit

[Ángel González]

Andreas Grünbacher wrote:
> Hi all,
> 
> the errexit option can be very useful in simple scripts. This option
> is being ignored in many contexts like lists and conditionals though.
> I understand that this is "by design" and that errexit cannot be
> "fixed" to behave more reasonably. Still, this makes bash a lot less
> useful than it could be; working around this limitation is painful,
> ugly, and leads to fragile code.
> 
> So, since we cannot "fix" errexit, can we maybe introduce another
> option like "errfail" that behaves like errexit for simple commands,
> but is also logically composable? Let me show what I mean with the
> following pseudo-code:

I think you should explicitely state where and you would like it not to
do it. I find unlikely to develop it, but at least they could be
documented, with its workarounds.
On some cases with non-POSIX features, maybe the behavior could be
changed for some non-POSIX (eg. the change of arighmetic expansion on
bash-4.1)

For reference, the current doc says:
>      if the
>      failed command is part of the command list immediately following
>      an `until' or `while' keyword, part of the test following the `if'
>      or `elif' reserved words, part of a command executed in a `&&' or
>      `||' list except the command following the final `&&' or `||', any
>      command in a pipeline but the last, or if the command's return
>      status is being inverted using `!'

> 
>    set -o errfail
>    fail() {
>       false
>       echo 'oops!' >&2  # not reached
>    }
>    ! fail
>    fail || :
>    if fail; then
>       :
>    fi
>    set -- `fail`  # script fails here
>    echo 'oops!' >&2  # not reached

This seems to request a change on two cases:
- inherit the errexit flag into functions
- make shell expansions fail the command including them


For the first one, I don't see a spec reason for that, other than "it
has been done like that", requiring an explicit set -o errfail. Maybe
the set options should be inherited for set -E


While we discuss it, I find odd that this code doesn't run the trap
inside a function but does outside:
> fail() {
>   trap "echo trap executed" ERR
>   false
> }


As for the second option, I also missed such a ability a while back, but
was able to get the expected behavior with the workaround:
> FAIL=$(fail)
> set -- $FAIL




> Having such an option would certainly make bash a lot more useful to me.
> What do you guys think, could such an option be implemented with
> reasonable effort?

I don't think it would require special effort, but IMHO adding a
_slightly different errexit_ wouldn't be appropiate. Changing errexit
semantic, has a big potential for broken scripts. And having readily
available workarounds…