Differences between revisions 6 and 7
Revision 6 as of 2011-11-01 18:42:09
Size: 1860
Editor: GreyCat
Comment: trap ERR too
Revision 7 as of 2012-09-27 04:42:46
Size: 2035
Editor: c74-197-124-13
Comment: Unbiasing a bit
Deletions are marked like this. Additions are marked like this.
Line 3: Line 3:
`set -e` was an attempt to add "automatic error detection" to the shell. Its ''goal'' was to cause the shell to abort any time an error occurred, so you don't have to put `|| exit 1` after each important command. `set -e` was an attempt to add "automatic error detection" to the shell. Its goal was to cause the shell to abort any time an error occurred, so you don't have to put `|| exit 1` after each important command.
Line 5: Line 5:
That goal is non-trivial, because many commands are ''supposed'' to return non-zero. For example, That goal is non-trivial, because many commands intentionally return non-zero. For example,
Line 8: Line 8:
  if [ -d /foo ]; then
   
...
 
else
   
...
 
fi
  if [ -d /foo ]; then ...; else ...; fi
Line 15: Line 11:
Clearly we don't want to abort when `[ -d /foo ]` returns non-zero (because the directory does not exist) -- our script wants to handle that in the `else` part. So the implementors decided to make a bunch of special rules, like "commands that are part of an `if` test are immune", or "commands in a pipeline, other than the last one, are immune". Clearly we don't want to abort when the conditional, `[ -d /foo ]`, returns non-zero (because the directory does not exist) -- our script wants to handle that in the `else` part. So the implementors decided to make a bunch of special rules, like "commands that are part of an `if` test are immune", or "commands in a pipeline, other than the last one, are immune".
Line 42: Line 38:

rking's personal recommendation is to go ahead and use `set -e`, but beware of possible gotchas. It has useful semantics, so to exclude it from the toolbox is to give into FUD.

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

set -e was an attempt to add "automatic error detection" to the shell. Its goal was to cause the shell to abort any time an error occurred, so you don't have to put || exit 1 after each important command.

That goal is non-trivial, because many commands intentionally return non-zero. For example,

  if [ -d /foo ]; then ...; else ...; fi

Clearly we don't want to abort when the conditional, [ -d /foo ], returns non-zero (because the directory does not exist) -- our script wants to handle that in the else part. So the implementors decided to make a bunch of special rules, like "commands that are part of an if test are immune", or "commands in a pipeline, other than the last one, are immune".

These rules are extremely convoluted, and they still fail to catch even some remarkably simple cases. Even worse, the rules change from one Bash version to another, as Bash attempts to track the extremely slippery POSIX definition of this "feature". When a SubShell is involved, it gets worse still -- the behavior changes depending on whether Bash is invoked in POSIX mode. Another wiki has a page that covers this in more detail. Be sure to check the caveats.

Exercise for the reader: why doesn't this example print anything?

   1 #!/bin/bash
   2 set -e
   3 i=0
   4 let i++
   5 echo "i is $i"

Exercise 2: why does this one sometimes appear to work? In which versions of bash does it work, and in which versions does it fail?

   1 #!/bin/bash
   2 set -e
   3 i=0
   4 ((i++))
   5 echo "i is $i"

(Answers)

GreyCat's personal recommendation is simple: don't use set -e. Add your own error checking instead.

rking's personal recommendation is to go ahead and use set -e, but beware of possible gotchas. It has useful semantics, so to exclude it from the toolbox is to give into FUD.

BashFAQ/105 (last edited 2021-03-11 06:07:25 by dsl-66-36-156-249)