Bash – How to catch and handle nonzero exit status within a Bash function

basherror handlingexitfunctionshell-script

Say I have the following (pointless) Bash function:

myfunc() {
    ls
    failfailfail
    uptime
}

I run it as follows:

myfunc || echo "Something is wrong."

What I want to happen is ls runs (as it should), failfailfail does not work (since it doesn't exist), and uptime doesn't run. The return value of the function would be nonzero, and the error message would be shown. The return value doesn't have to be the exact exit status of the failed command, it just shouldn't be zero.

What actually happens is I get the output of ls, followed by "-bash: failfailfail: command not found", followed by the output of uptime. The error message is not shown, because the failed exit status is getting eaten.

set -e has no useful effect, either within the function or in the scope where the function is called. The only way I can get this to work the way I want is:

myfunc() {
    ls || return $?
    failfailfail || return $?
    uptime || return $?
}

But this seems awfully repetitive and ugly. Is there another way to clean this up?

Best Answer

Under set -e, the non-existence of failfailfail causes the whole script to exit (or the subshell, if the function is executed in a subshell).

If you don't need to modify the shell state from the function, you can run it in a subshell.

myfunc() (
    set -e
    ls
    failfailfail
    uptime
)

Another approach in bash is to set an ERR trap to execute return. If you want to make it a local setting, you need to restore the old trap value, which is a little cumbersome.

myfunc() {
    local old_ERR_trap=$(trap -p ERR)
    if [[ -z $old_ERR_trap ]]; then old_ERR_trap="trap - ERR"; fi
    trap 'local ret=$?; eval "$old_ERR_trap"; return $ret' ERR
    ls
    failfailfail
    uptime
}

Related Solutions

Bash – How to combine bash command grouping and pipe status

When you execute a pipeline, each pipe-separated element is executed in its own process. Variable assignments only take effect in their own process. Under ksh and zsh, the last element of the pipeline is executed in the original shell; under other shells such as bash, each pipeline element is executed in its own subshell and the original shell just waits for them all to end.

$ bash -c 'GROUPSTATUS=foo; echo GROUPSTATUS is $GROUPSTATUS'
GROUPSTATUS is foo
$ bash -c 'GROUPSTATUS=foo | :; echo GROUPSTATUS is $GROUPSTATUS'
GROUPSTATUS is

In your case, since you only care about all the commands succeeding, you can make the status code flow up.

{ tar -cf - my_folder 2>&1 1>&3 | grep -v "Removing leading" 1>&2;
  ! ((PIPESTATUS[0])); } 3>&1 |
gzip --rsyncable > my_file.tar.gz;
if ((PIPESTATUS[0] || PIPESTATUS[1])); then rm my_file.tar.gz; fi

If you want to get more than 8 bits of information out of the left side of a pipe, you can write to yet another file descriptor. Here's a proof-of-principle example:

{ { tar …; echo $? >&4; } | …; } | { gzip …; echo $? >&4; } \
  4>&1 | ! grep -vxc '0'

Once you get data on standard output, you can feed it into a shell variable using command substitution, i.e. $(…). Command substitution reads from the command's standard output, so if you also meant to print things to script's standard output, they need to temporarily go through another file descriptor. The following snippet uses fd 3 for things that eventually go to the script's stdout and fd 4 for things that are captured into $statuses.

statuses=$({ { tar -v … >&3; echo tar $? >&4; } | …; } |
           { gzip …; echo gzip $? >&4; } 4>&1) 3>&1

If you need to capture the output from different commands into different variables, I think there is no direct way even in “advanced” shells such as bash, ksh or zsh. Here are some workarounds:

Use temporary files.
Use a single output stream, with e.g. a prefix on each line to indicate its origin, and filter at the top level.
Use a more advanced language such as Perl or Python.

Bash Shell Script – How to Exit on Backtick Failure Similar to Pipefail

Solution

If you are running Bash 4.4 or later, you can use the shopt option inherit_errexit to do just that. You can check compatibility from within Bash using echo $BASH_VERSION.

Here is the shebang you would use if Bash 4.4 or later were installed and came before /bin in your $PATH:

#!/usr/bin/env -S bash -euET -o pipefail -O inherit_errexit

The -S is there to coax Linux’s env into accepting more than one argument for bash, as kindly pointed out by @UVV and explained further on StackOverflow.

Background

inherit_errexit is an option to shopt, while the rest of the arguments are options to set. In most modern iterations, they can be passed directly to bash when invoking the shell.

Let’s review the options you have already been using:

-u/-o nounset, as the name ambiguously hints, disallows dereferencing of variables that have not been set; e.g., $IJUSTMADETHISUP.
-e/-o errexit does some of what you are requesting: it causes directly called shell commands with nonzero return values to cause the shell to exit entirely.
-o pipefail is needed to extend this to commands whose output is redirected with an I/O pipe |.

Now for the options I’ve added:

-O inherit_errexit further extends this functionality (exiting on nonzero status code) to commands called from within subshells $(...).
The -E/-o errtrace and -T/-o functrace options are there for the comparatively rare case that you use trap to perform an action when the shell receives a signal. These two options extend signal handlers to the inner bodies of shell functions for ERR signals and DEBUG/RETURN signals, respectively.