587

I have a Bash shell script that invokes a number of commands.

I would like to have the shell script automatically exit with a return value of 1 if any of the commands return a non-zero value.

Is this possible without explicitly checking the result of each command?

For example,

dosomething1
if [[ $? -ne 0 ]]; then
    exit 1
fi

dosomething2
if [[ $? -ne 0 ]]; then
    exit 1
fi
Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Jin Kim
  • 16,562
  • 18
  • 60
  • 86
  • 23
    In addition to `set -e`, also do `set -u` (or `set -eu`). `-u` puts an end to the idiotic, bug-hiding behavior that you can access any nonexistent variable and have a blank value produced with no diagnostics. – Kaz Feb 21 '14 at 01:36
  • Unofficial Bash Strict Mode: http://redsymbol.net/articles/unofficial-bash-strict-mode/ – Hari May 12 '23 at 20:50

10 Answers10

945

Add this to the beginning of the script:

set -e

This will cause the shell to exit immediately if a simple command exits with a nonzero exit value. A simple command is any command not part of an if, while, or until test, or part of an && or || list.

See the bash manual on the "set" internal command for more details.

It's really annoying to have a script stubbornly continue when something fails in the middle and breaks assumptions for the rest of the script. I personally start almost all portable shell scripts with set -e.

If I'm working with bash specifically, I'll start with

set -Eeuo pipefail

This covers more error handling in a similar fashion. I consider these as sane defaults for new bash programs. Refer to the bash manual for more information on what these options do.

Ville Laurikari
  • 28,380
  • 7
  • 60
  • 55
  • 42
    That would work, but I like to use "#!/usr/bin/env bash" because I frequently run bash from somewhere other than /bin. And "#!/usr/bin/env bash -e" doesn't work. Besides, it's nice to have a place to modify to read "set -xe" when I want to turn on tracing for debugging. – Ville Laurikari May 04 '09 at 19:25
  • 4
    Bear in mind that this might not be enough because of pipelines. See my added answer. – leonbloy Dec 03 '10 at 14:23
  • 54
    Also, the flags on the shebang line are ignored if a script gets run as `bash script.sh`. – Tom Anderson Dec 03 '10 at 14:26
  • 37
    Just a note: If you declare functions inside the bash script, the functions will need to have set -e redeclared inside the function body if you want to extend this functionality. – Jin Kim Oct 19 '12 at 17:40
  • 9
    Also, if you source your script, the shebang line will be irrelevent. –  Apr 14 '13 at 16:17
  • 7
    @JinKim That doesn't appear to be the case in bash 3.2.48. Try the following inside a script: `set -e; tf() { false; }; tf; echo 'still here'`. Even without `set -e` inside the body of `tf()`, execution is aborted. Perhaps you meant to say that `set -e` is not inherited by *subshells*, which is true. – mklement0 Apr 16 '13 at 04:53
  • @VilleLaurikari This is for existed commands, but how to know the status of manual commands(suppose if i executed a program how to know it's status whether it success or any error). I have a scenario to implement where i have to execute N commands(each one running as a thread), when any one of them fails i have to exit the script. – Siva Krishna Aleti Dec 27 '13 at 03:24
  • 1
    You can also disable failing on errors with `set +e` again later in your script. – orkoden Apr 08 '14 at 15:30
  • 1
    This is a good answer - but test carefully. -e (errexit) is inconsistent in different versions of bash, and unless you know your script very well you could be caught out by errors in commands like pipes or if-thens. You'll catch the errors you want to catch, but in a complex script you won't catch every error. – andrew lorien Feb 17 '15 at 06:34
  • So there are some commands in the script which even if fails does not terminate the script.. Is there a way to put exceptions for specific commands with having set -e in the script? – codersofthedark Apr 12 '17 at 08:55
269

To add to the accepted answer:

Bear in mind that set -e sometimes is not enough, specially if you have pipes.

For example, suppose you have this script

#!/bin/bash
set -e 
./configure  > configure.log
make

... which works as expected: an error in configure aborts the execution.

Tomorrow you make a seemingly trivial change:

#!/bin/bash
set -e 
./configure  | tee configure.log
make

... and now it does not work. This is explained here, and a workaround (Bash only) is provided:

#!/bin/bash
set -e 
set -o pipefail

./configure  | tee configure.log
make
ndmeiri
  • 4,979
  • 12
  • 37
  • 45
leonbloy
  • 73,180
  • 20
  • 142
  • 190
  • 5
    Thank you for explaining the importance of having `pipefail` to go along with `set -o` ! – Malcolm Apr 26 '18 at 16:48
  • It is possibly worth noting that combination of -o pipefail and -e work well in bash. But they don't in ksh (93) from where bash picked this feature. There an extra check after pipes is required to exit the shell with an error. – toaster Mar 22 '22 at 12:07
102

The if statements in your example are unnecessary. Just do it like this:

dosomething1 || exit 1

If you take Ville Laurikari's advice and use set -e then for some commands you may need to use this:

dosomething || true

The || true will make the command pipeline have a true return value even if the command fails so the the -e option will not kill the script.

Zan Lynx
  • 53,022
  • 10
  • 79
  • 131
  • 1
    I like this. Especially because the top answer is bash-centric (not at all clear to me whether/to what extent it applies to zsh scripting). And I could look it up, but your is just clearer, because logic. –  May 19 '15 at 15:09
  • 1
    `set -e` is not bash-centric - it is supported even on the original Bourne Shell. – Marcos Vives Del Sol Apr 22 '20 at 17:38
  • For reference, these operators are referred to as control operators. More info here: https://opensource.com/article/18/11/control-operators-bash-shell – Hannes Nel Jan 18 '21 at 22:29
30

If you have cleanup you need to do on exit, you can also use 'trap' with the pseudo-signal ERR. This works the same way as trapping INT or any other signal; bash throws ERR if any command exits with a nonzero value:

# Create the trap with   
#    trap COMMAND SIGNAME [SIGNAME2 SIGNAME3...]
trap "rm -f /tmp/$MYTMPFILE; exit 1" ERR INT TERM
command1
command2
command3
# Partially turn off the trap.
trap - ERR
# Now a control-C will still cause cleanup, but
# a nonzero exit code won't:
ps aux | grep blahblahblah

Or, especially if you're using "set -e", you could trap EXIT; your trap will then be executed when the script exits for any reason, including a normal end, interrupts, an exit caused by the -e option, etc.

Nails N.
  • 561
  • 4
  • 11
18

The $? variable is rarely needed. The pseudo-idiom command; if [ $? -eq 0 ]; then X; fi should always be written as if command; then X; fi.

The cases where $? is required is when it needs to be checked against multiple values:

command
case $? in
  (0) X;;
  (1) Y;;
  (2) Z;;
esac

or when $? needs to be reused or otherwise manipulated:

if command; then
  echo "command successful" >&2
else
  ret=$?
  echo "command failed with exit code $ret" >&2
  exit $ret
fi
Mark Edgar
  • 4,707
  • 2
  • 24
  • 18
  • 3
    Why "should always be written as"? I mean, why "*should*" it be so? When a command is long (think invoking GCC with a dozen options), then it is much more readable to run the command before checking the return status. – ysap Sep 08 '12 at 12:50
  • 1
    If a command is too long, you can break it up by naming it (define a shell function). – Mark Edgar Nov 10 '12 at 23:27
  • See [Why is testing “$?” to see if a command succeeded or not, an anti-pattern?](https://stackoverflow.com/questions/36313216/why-is-testing-to-see-if-a-command-succeeded-or-not-an-anti-pattern) – tripleee May 11 '21 at 06:42
  • How do you capture the output of the command and check if it returned successful like this? – Quazil Sep 29 '22 at 16:12
15

Run it with -e or set -e at the top.

Also look at set -u.

fedorqui
  • 275,237
  • 103
  • 548
  • 598
lumpynose
  • 967
  • 4
  • 12
  • 41
    To potentially save others the need to read through `help set`: `-u` treats references to unset variables as errors. – mklement0 Apr 16 '13 at 04:31
  • 1
    so it's either `set -u` or `set -e`, not both? @lumpynose – ericn Jun 01 '16 at 07:46
  • 1
    @eric I retired several years ago. Even though I loved my work my aged brain has forgotten everything. Offhand I'd guess that you could use both together; bad wording on my part; I should have said "and/or". – lumpynose Jun 01 '16 at 17:37
10

On error, the below script will print a RED error message with the failed command and then will exit.
Put this at the top of your bash script:

# BASH error handling:
#   exit on command failure
set -e
#   keep track of the last executed command
trap 'LAST_COMMAND=$CURRENT_COMMAND; CURRENT_COMMAND=$BASH_COMMAND' DEBUG
#   on error: print the failed command
trap 'ERROR_CODE=$?; FAILED_COMMAND=$LAST_COMMAND; tput setaf 1; echo "ERROR: command \"$FAILED_COMMAND\" failed with exit code $ERROR_CODE"; put sgr0;' ERR INT TERM
ShaulF
  • 841
  • 10
  • 17
4
#!/bin/bash -e

should suffice.

Frits
  • 7,341
  • 10
  • 42
  • 60
Baligh Uddin
  • 49
  • 1
4

An expression like

dosomething1 && dosomething2 && dosomething3

will stop processing when one of the commands returns with a non-zero value. For example, the following command will never print "done":

cat nosuchfile && echo "done"
echo $?
1
gabor
  • 1,030
  • 3
  • 12
  • 23
-3

I am just throwing in another one for reference since there was an additional question to Mark Edgars input and here is an additional example and touches on the topic overall:

[[ `cmd` ]] && echo success_else_silence

Which is the same as cmd || exit errcode as someone showed.

For example, I want to make sure a partition is unmounted if mounted:

[[ `mount | grep /dev/sda1` ]] && umount /dev/sda1
Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Malina
  • 9