The first statement is a Mac, GNU/Linux, and BSD portable way of finding the location of the bash interpreter. The second statement combines...
#!/usr/bin/env bash set -euo pipefail
The first statement is a Mac, GNU/Linux, and BSD portable way of finding the location of the bash interpreter. The second statement combines
-
- “set -e” which ensures that your script stops on first command failure. By default, when a command fails, BASH executes the next command. Looking at the logs, you might feel that the script executed successfully while some commands might have failed. Caveat: Be careful about applying it to existing scripts.
- “set -u” which ensures that your script exits on the first unset variable encountered. Otherwise, bash replaces the unset variables with empty default values.
- “set -o pipefail” which ensures that if any command in a set of piped commands failed, the overall exit status is the status of the failed command. Otherwise, the exit status is the status of the last command.
References:
No. Both ‘set -e’ and ‘set -u’ have huge problems! They often cause more problems than the solve. You should use proper error handling or at least use TRAPS instead.
See for example:
https://wiki.bash-hackers.org/scripting/obsolete
From the link, you pointed. “The ERR trap is not POSIX, but set -e is” and “Do not be tempted to think of this as “error handling”; it’s not, it’s just a way to find the place you’ve forgotten to put error handling.”. And I agree with both, `set -e` is great since it is easy to implement when proper error handling is hard. Error trapping would have been great but it is not widespread. It reminds me of why Google prohibits C++ exception handling since it’s not wide-spread (“Given that Google’s existing code is not exception-tolerant, the costs of using exceptions are somewhat greater than the costs in a new project. The conversion process would be slow and error-prone. We don’t believe that the available alternatives to exceptions, such as error codes and assertions, introduce a significant burden.” – https://google.github.io/styleguide/cppguide.html#Exceptions). I want to follow the same for BASH since error trapping in BASH is uncommon while copy-pasting code from the Internet is common.