Starting a script with #! /path/to/bash -option
, or equivalently running
bash -option /path/to/script
, has the same effect as inserting set -option
inside the script just after its #!
line.
set -x
is essentially just for debugging; you wouldn't want it left on normally.
The effect of set -e
is a lot more complicated than the manual suggests. The more precise description is roughly:
After invoking set -e
, if an untested command exits with a non-zero status, it will cause the shell to exit with that exit status.
I say more precise because it's still pretty vague: the list of situations where the command is considered tested is arcane and difficult to predict. The exact rules differ between shells and even change between versions of the same shell.
set -e
does not cause Bash to exit in response to non-zero exit status of any commands:
- between
if
/elif
and then
; or
- between
while
/until
and do
; or
- following
!
; or
- followed by
||
or &&
or &
(though for &
the corresponding wait
or fg
may fail); or
- followed by
|
, unless set -o pipefail
is in effect; or
- inside
$( ... )
when used as part of a command (not bare assignments and/or redirections, which means that foo=$( bar )
will fail if bar
fails, but local foo=$( bar )
will not); or
- within a compound command where the above apply; or
- inside a shell function invoked from anywhere the above apply.
The effects on compound commands and shell functions are recursive.
Because the shell itself exits with a non-zero status, the effect can propagate out of a subshell.
The !
exemption applies even if the inverted exit status is ignored.
Conversely, set -e
triggers on every other non-zero status, regardless of whether it means "fail" or simply "false". For example ((x++))
will have a non-zero "fail" exit status when x
is initially 0.
Because it's such a mess, there's a school of thought that says set -e
should be avoided in favour of explicitly checking all commands.
Or if you still want to use set -e
, remember to write !
in front of any ((arithmetic))
groups.