What does 'set -e' mean in a Bash script?

Question

I'm studying the content of this preinst file that the script executes before that package is unpacked from its Debian archive (.deb) file.

The script has the following code:

#!/bin/bash
set -e
# Automatically added by dh_installinit
if [ "$1" = install ]; then
   if [ -d /usr/share/MyApplicationName ]; then
     echo "MyApplicationName is just installed"
     return 1
   fi
   rm -Rf $HOME/.config/nautilus-actions/nautilus-actions.conf
   rm -Rf $HOME/.local/share/file-manager/actions/*
fi
# End automatically added section

My first query is about the line:

set -e

I think that the rest of the script is pretty simple: It checks whether the Debian/Ubuntu package manager is executing an install operation. If it is, it checks whether my application has just been installed on the system. If it has, the script prints the message "MyApplicationName is just installed" and ends (return 1 means that the script exits with an error, doesn’t it?).

If the user is asking the Debian/Ubuntu package system to install my package, the script also deletes two directories.

Is this right or am I missing something?

Answer 1

I'm belatedly posting a separate answer about the specific code in the question. It has multiple issues.

# Automatically added by dh_installinit

This is slightly misleading, in that the author of the script has apparently modified the code which was actually automatically added.

if [ "$1" = install ]; then

The preinst script will run in multiple circumstances, and receive an argument which indicates which scenario is causing it to be called. This section will get run if the action is install (and not, for example, upgrade or abort-upgrade, which are the other two possible values; see https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html)

   if [ -d /usr/share/MyApplicationName ]; then
     echo "MyApplicationName is just installed"
     return 1
   fi

This seems suspicious. The echo command might not be printing to anywhere useful, and return 1 causes the entire installation to fail.

More tangentially, MyApplicationName has aberrant capitalization; a typical value would be more like my_application or my-application

   rm -Rf $HOME/.config/nautilus-actions/nautilus-actions.conf
   rm -Rf $HOME/.local/share/file-manager/actions/*

These too seem highly suspicious. The package management system should not touch any non-system files, for any user. Moreover, $HOME is probably going to be /root when this script runs, so whatever the author hoped to accomplish here is probably not actually going to happen.

Answer 2

None of the other answers here discuss the use of set -e aka set -o errexit in Debian package handling scripts. The use of this option is strongly recommended in these scripts, per Debian policy; the intent is apparently to avoid any possibility of an unhandled error condition.

In practice, this means that you have to understand under what conditions the commands you run could return an error, and handle each of those errors explicitly.

Common gotchas are, e.g., diff (returns an error when there is a difference) and grep (returns an error when there is no match). You can avoid the errors with explicit handling:

diff this that ||
  echo "$0: there was a difference" >&2
grep cat food ||
  echo "$0: no cat in the food" >&2

(Notice also how we take care to include the current script's name in the message, and writing diagnostic messages to standard error instead of standard output.)

Perhaps notice also that arithmetic evaluation can have this effect.

((variable++))

will fail if variable is zero.

If no explicit handling is really necessary or useful, explicitly do nothing:

diff this that || true
grep cat food || :

(The use of the shell's : no-op command is slightly obscure, but fairly commonly seen.)

Just to reiterate,

something || other

is shorthand for

if something; then
    : nothing
else
    other
fi

i.e., we explicitly say other should be run if and only if something fails. The longhand if (and other shell flow control statements like while, until) is also a valid way to handle an error (indeed, if it weren't, shell scripts with set -e could never contain flow control statements!)

And also, just to be explicit, in the absence of a handler like this, set -e would cause the entire script to immediately fail with an error if diff found a difference, or if grep didn't find a match.

On the other hand, some commands don't produce an error exit status when you'd want them to. Commonly problematic commands are find (exit status does not reflect whether files were actually found) and sed (exit status won't reveal whether the script received any input or actually performed any commands successfully). A simple guard in some scenarios is to pipe to a command which does scream if there is no output:

find things | grep .
sed -n 's/o/me/p' stuff | grep ^

It should be noted that the exit status of a pipeline is the exit status of the last command in that pipeline. So the above commands actually completely mask the status of find and sed, and only tell you whether grep finally succeeded.

(Bash, of course, has set -o pipefail, which throws an error if any command in a pipeline failed; but Debian package scripts cannot use Bash features. The policy firmly dictates the use of POSIX sh for these scripts, though this was not always the case.)

In many situations, this is something to separately watch out for when coding defensively. Sometimes you have to e.g. go through a temporary file so you can see whether the command which produced that output finished successfully, even when idiom and convenience would otherwise direct you to use a shell pipeline.

Answer 3

From help set and Bash Reference Documentation: The Set Builtin:

  -e  Exit immediately if a command exits with a non-zero status.

But it's considered bad practice by some (Bash FAQ and IRC Freenode #bash FAQ authors). It's recommended to use:

trap 'do_something' ERR

to run do_something function when errors occur.

See Why doesn't set -e (or set -o errexit, or trap ERR) do what I expected?

Answer 4

set -e means that the reader of the script cannot know what the script will do when looking at code snippets out of context. (This is a bit tongue-in-cheek, but gets to the heart of the matter.) I have been opposed to the use of errexit for many years and have recently been doing a fair bit of work in an environment where shell snippets are accumulated as templates. errexit is enabled by default in this environment, but that is largely irrelevant as any previous snippet may disable errexit and the order in which the templates are gathered is not well known and probably non-deterministic. But consider the simple case in which you look at a few lines without context in a shell script:

$ sed -n 3,6p sample-script 
echo this will be printed
set -e  # enable errexit again just to be sure it's on
false
echo but errexit is enabled so this will not be printed

Since errexit is enabled, the reader is being very reasonable in expecting that the line "but errexit is enabled so this will not be printed" will not in fact be written. But, consider the actual execution of the script:

$ ./sample-script 
this will be printed
but errexit is enabled so this will not be printed

There is no magical juju happening, or anything terribly bizarre that is causing this behavior. This is simply the normal behavior of the shell. On the other hand, if we change the script slightly and make the desired behavior explicit, the unexpected behavior goes away. Consider:

$ cat sample-script-2 
#!/bin/bash -e
if
echo this will be printed
false || exit
echo but this is not printed because the author was explicit about exiting
then : ; fi
$ ./sample-script-2 
this will be printed

errexit was an attempt to make life easier for script writers and maintainers, but it failed. And it continues to fail. To borrow from python: "Explicit is better than implicit". If you want your script to terminate if a command returns non-zero, write cmd || exit. If you want your script to maybe sometimes fail when a command returns non-zero and you want to ensure that the maintainers of the script really won't know what actually happens, write set -e; cmd

Answer 5

set -e The set -e option instructs Bash to immediately exit if any command 1 has a non-zero exit status. You wouldn't want to set this for your command-line shell, but in a script it's massively helpful.

In all widely used general-purpose programming languages, an unhandled runtime error - whether that's a thrown exception in Java, or a segmentation fault in C, or a syntax error in Python - immediately halts execution of the program; subsequent lines are not executed.

• By default, Bash does not do this. This default behavior is exactly what you want if you are using Bash on the command line
• you don't want a typo to log you out! But in a script, you really want the opposite.
• If one line in a script fails, but the last line succeeds, the whole script has a successful exit code. That makes it very easy to miss the error.
• Again, what you want when using Bash as your command-line shell and using it in scripts are at odds here. Being intolerant of errors is a lot better in scripts, and that's what set -e gives you.

Copied from: Bash strict mode

Answer 6

Script 1: without setting -e

#!/bin/bash
decho "hi"
echo "hello"

This will throw an error in the line with decho and the program continues to the next line.

Script 2: With setting -e

#!/bin/bash
set -e
decho "hi"
echo "hello"

Up to decho "hi", the shell will process and the program exit. It will not proceed further.

Answer 7

I believe the intention is for the script in question to fail fast.

To test this yourself, simply type set -e at a Bash prompt. Now, try running ls. You'll get a directory listing. Now, type lsd. That command is not recognized and will return an error code, and so your Bash prompt will close (due to set -e).

Now, to understand this in the context of a 'script', use this simple script:

#!/bin/bash
# set -e

lsd

ls

If you run it as is, you'll get the directory listing from the ls on the last line. If you uncomment the set -e and run again, you won't see the directory listing as bash stops processing once it encounters the error from lsd.

Answer 8

It stops execution of a script if a command fails.

A notable exception is an if statement. eg:

set -e
false
echo never executed

set -e
if false; then
  echo never executed
fi

echo executed

false

echo never executed

Answer 9

cat a.sh
#! /bin/bash

#going forward report subshell or command exit value if errors
#set -e
(cat b.txt)
echo "hi"

./a.sh; echo $?
cat: b.txt: No such file or directory
hi
0

with set -e commented out we see that echo "hi" exit status being reported and hi is printed.

cat a.sh
#! /bin/bash

#going forward report subshell or command exit value if errors
set -e
(cat b.txt)
echo "hi"

./a.sh; echo $?
cat: b.txt: No such file or directory
1

Now we see b.txt error being reported instead and no hi printed.

So default behaviour of shell script is to ignore command errors and continue processing and report exit status of last command. If you want to exit on error and report its status we can use -e option.

Answer 10

I found this post while trying to figure out what the exit status was for a script that was aborted due to a set -e. The answer didn't appear obvious to me; hence this answer. Basically, set -e aborts the execution of a command (e.g. a shell script) and returns the exit status code of the command that failed (i.e. the inner script, not the outer script).

For example, suppose I have the shell script outer-test.sh:

#!/bin/sh
set -e
./inner-test.sh
exit 62;

The code for inner-test.sh is:

#!/bin/sh
exit 26;

When I run outer-script.sh from the command line, my outer script terminates with the exit code of the inner script:

$ ./outer-test.sh
$ echo $?
26

Answer 11

As per bash - The Set Builtin manual, if -e/errexit is set, the shell exits immediately if a pipeline consisting of a single simple command, a list or a compound command returns a non-zero status.

By default, the exit status of a pipeline is the exit status of the last command in the pipeline, unless the pipefail option is enabled (it's disabled by default).

If so, the pipeline's return status of the last (rightmost) command to exit with a non-zero status, or zero if all commands exit successfully.

If you'd like to execute something on exit, try defining trap, for example:

trap onexit EXIT

where onexit is your function to do something on exit, like below which is printing the simple stack trace:

onexit(){ while caller $((n++)); do :; done; }

There is similar option -E/errtrace which would trap on ERR instead, e.g.:

trap onerr ERR

Examples

Zero status example:

$ true; echo $?
0

Non-zero status example:

$ false; echo $?
1

Negating status examples:

$ ! false; echo $?
0
$ false || true; echo $?
0

Test with pipefail being disabled:

$ bash -c 'set +o pipefail -e; true | true | true; echo success'; echo $?
success
0
$ bash -c 'set +o pipefail -e; false | false | true; echo success'; echo $?
success
0
$ bash -c 'set +o pipefail -e; true | true | false; echo success'; echo $?
1

Test with pipefail being enabled:

$ bash -c 'set -o pipefail -e; true | false | true; echo success'; echo $?
1

Answer 12

set -e stops the execution of a script if a command or pipeline has an error - which is the opposite of the default shell behaviour, which is to ignore errors in scripts. Type help set in a terminal to see the documentation for this built-in command.