What does set -e mean in a bash script?

问题:

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 mean that ends 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?

回答1:

From help set :

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

But it\'s considered as a bad practice by some people (bash FAQ and such like people writing this FAQ on irc freenode #bash), better use :

trap \'do_something\' ERR

to run do_something function when errors will occurs.

See http://mywiki.wooledge.org/BashFAQ/105

回答2:

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.

回答3:

As per bash - The Set Builtin manual, if -e/errexit is set, shell exits immediately if a pipeline consist 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

回答4:

I found this question while Googling, 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 a 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

回答5:

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.

回答6:

This is an old question, but none of the answers here discuss the use of set -e aka set -o errexit in Debian package handling scripts. The use of this option is mandatory in these scripts, per Debian policy; the intent is apparently to avoid any possibility of an unhandled error condition.

What this means in practice is 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.)

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 -e \'s/o/me/\' 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; 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.