How to determine when Bash's "exit immediately" option (set -e) is being ignored

The manual for the Bash shell provides the following information in the section that describes the set -e builtin option:

> If a compound command or shell function executes in a context where -e is being ignored, none of the commands executed within the compound command or function body will be affected by the -e setting, even if -e is set and a command returns a failure status. If a compound command or shell function sets -e while executing in a context where -e is ignored, that setting will not have any effect until the compound command or the command containing the function call completes.

I've encountered a problem with a Bash script I'm writing where I'm setting the -e flag, but the script does not exit when a command returns a non-zero exit status code. This is occurring within a called function, e.g.,

Listing 1

set -e
function foo ()
{
    set -e
    ls zzzz     # 'zzzz' doesn't exist
    ...   # <- these statements are executed
}
foo
...  # <- these statements are executed

I know I can use Bash's builtin variable $- to display the options that are currently set. When I do this in my actual script, the -e option is set: ehuB. Nevertheless, the called function does not exit when it executes a statement that returns a non-zero exit status. So, I'm assuming the called function must be executing within a context where -e is being ignored.

Listing 2

set -e
function foo ()
{
    set -e
    echo "settings=$-"    # ehuB
    ls zzzz     # 'zzzz' doesn't exist
    ...   # <- these statements are executed
}
echo "settings=$-"    # ehuB
foo
...  # <- these statements are executed

So my question is this: how can I programmatically test to determine that a section of code in a Bash script is or isn't executing within a context where -e is being ignored?

Additionally, what conditions create an execution context where the -e option (when set) is ignored?

> what conditions create an execution context where the -e option (when set) is ignored?

Is documented in:

> -e
>
> Exit immediately if a pipeline (see Pipelines), which may consist of a
> single simple command (see Simple Commands), a list (see Lists of
> Commands), or a compound command (see Compound Commands) returns a
> non-zero status. The shell does not exit if the command that fails is
> part of the command list immediately following a while or until
> keyword, part of the test in an if statement, part of any 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 with !. If a compound command other
> than a subshell returns a non-zero status because a command failed
> while -e was being ignored, the shell does not exit. A trap on ERR, if
> set, is executed before the shell exits.
>
> This option applies to the shell environment and each subshell
> environment separately (see Command Execution Environment), and may
> cause subshells to exit before executing all the commands in the
> subshell.
>
> If a compound command or shell function executes in a context where -e
> is being ignored, none of the commands executed within the compound
> command or function body will be affected by the -e setting, even if
> -e is set and a command returns a failure status. If a compound command or shell function sets -e while executing in a context where
> -e is ignored, that setting will not have any effect until the compound command or the command containing the function call
> completes.

> How to determine when Bash's "exit immediately" option (set -e) is being ignored

This is like my decision tree:

• Is the command called from if, while or until? -> ignored
• Is the command prefixed with ! ? -> ignored
• Is the command in assignment of export, declare, typeset or local? -> ignored
• Not ignored.

Also remember about inheritance:

• Is this an asynchronous command?
  • Is this a process substitution, like echo < <(false; echo test >&2)?
  • Is this inside a part of a pipeline, like { false; echo test >&2; } | echo?
  • Is this inside coproc?
  • then set -e is inherited
• Are you in a subshell () ?
  • then is errexit_inherit set?

There is also a logic what is the actual exit status of chain of commands like.

• in 99% of contexts, the exit status of a block of commands is the exit status of last command executed
• What is the exit status of a && b || c vs a || b && c?
• Is lastpipe set?
• What is the exit status of if block? (last command executed). Ex. set -e; ( if true; then false; fi )?

Note that I am using set -e in my scripts. I am not forcing it on other people. And there are scripts that you want to continue when one of the commands fails.

> how can I programmatically test to determine that a section of code in a Bash script is or isn't executing within a context where -e is being ignored?

You can't.

You could write a bash builtin to access exit_immediately_on_error but it is reset here https://github.com/bminor/bash/blob/ec8113b9861375e4e17b3307372569d429dec814/execute_cmd.c#L4890 before executing the builtin. Also, the checks are not really simple like https://github.com/bminor/bash/blob/ec8113b9861375e4e17b3307372569d429dec814/execute_cmd.c#L2792 so I do not see a way.

I could have put this in comments area, but put as an answer for formatting purposes.

Can you run following script and post results :

#!/bin/bash
set -e
trap
function foo ()
{
    set -e
    echo $BASH_VERSION
    ls zzzz     
    echo "After ls"
}
echo "$(foo)"
echo "After subshell of foo"
echo -e "\nNow, going to do a direct call..."
foo
echo "After direct call of foo"

Mine gives result :

ls: cannot access 'zzzz': No such file or directory
5.1.16(1)-release
After subshell of foo
Now, going to do a direct call...
5.1.16(1)-release
ls: cannot access 'zzzz': No such file or directory
Exit code : 2