0

I have the following bash script. I set errexit (set -e) and am expecting the function to exit after the bad cd command.

#!/bin/bash
set -e


wtf() {
    cd non_existent_directory
    echo "SHOULD EXIT BEFORE THIS PRINTS"
}

wtf || echo "WORKED AS EXEPECTED"

But sadly it doesn't:

$ ./wtf.sh 
./wtf.sh: line 6: cd: non_existent_directory: No such file or directory
SHOULD EXIT BEFORE THIS PRINTS

How can I make it exit before that echo? I looked at the -e option here :http://www.tldp.org/LDP/abs/html/options.html and can't see why this wouldn't work?

gcc
  • 283
  • 1
  • 3
  • 14
  • 2
    This is already covered in the knowledgebase -- give me a minute to find it. In the interim, read [BashFAQ #105](http://mywiki.wooledge.org/BashFAQ/105). And please, please stop using the ABS as a resource -- it's the w3schools of bash, full of inaccurate and misleading advice. – Charles Duffy Nov 08 '16 at 23:46
  • @CharlesDuffy I can't find the duplicate? Is the solution just to use `|| return 1` after every command or is there something more elegant? – gcc Nov 09 '16 at 00:44
  • It's linked -- see "This question already has an answer here:", given at the top of the question. – Charles Duffy Nov 09 '16 at 00:55
  • 1
    As an additional reference, by the way, you might also find http://fvue.nl/wiki/Bash:_Error_handling useful. (Personally, I'm staunchly on the "against" side of this debate, arguing that folks writing scripts should do their own error handling rather than use a "feature" that behaves differently based on a wide array of both runtime context and shell-release-specific behaviors and which is thus neither elegant nor robust, but the page in question covers both ends). – Charles Duffy Nov 09 '16 at 00:57
  • Agreed. Thank you very much! – gcc Nov 09 '16 at 01:12
  • @CharlesDuffy scripts should do their own error handling *and* use set -e just like drivers should drive carefully *and* fasten their (unreliable) seat belt. – MarcH Nov 14 '18 at 17:18
  • @MarcH, `set -e` *decreases* reliability, it doesn't increase it: It creates new failure modes by making code behave differently based on its context. (Call a function from top level? Whether `set -e` is suppressed therein depends on whether something was branching on that function's result, so now you need to write it to be correct in two completely different contexts rather than just one). – Charles Duffy Nov 14 '18 at 17:40
  • 1
    @MarcH, ...similarly, a car with an extra set of brakes that works correctly 80% of the time, fails unexpectedly 20% (better hope the driver had their foot near the main brakes as well!), and also deploys unexpectedly another 2% of the time wouldn't be accepted by anyone. – Charles Duffy Nov 14 '18 at 17:44
  • Functions have to be correct in only one "context" because... they do their own, proper error handling. They may not get to choose whether they're called with errexit or not anyway, so one more reason to implement their own error handling as you recommended yourself. – MarcH Nov 14 '18 at 17:46

0 Answers0