[Top][All Lists]

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

Re: [RFC] Logically composable variant of errexit

From: Ángel González
Subject: Re: [RFC] Logically composable variant of errexit
Date: Thu, 09 Oct 2014 21:08:54 +0200

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

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…

reply via email to

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