I feel the same way with Bash.
It's great for one liners, but it breaks down when doing simple things like checking if a variable is a string or integer.
It's great for one liners, but it breaks down when doing simple things like checking if a variable is a string or integer.
set -euo pipefail
I've seen way too many scripts catastrophically fail because of unbound variables or one side of a pipe failing and the script continuing anyways, etc.-e Abort at the first failed line
-u Abort when undefined variable is used
-o pipefail Piped commands return the status of the last failed command, rather than the status of the last command
set -o errexit
set -o nounset
set -o pipefail
Some commands need custom error handling, which means turning off -e: set +o errexit
ansible-playbook ...
if [[ "$?" != "0" ]]; then
echo -e "\e[1;31m""Error when executing ansible!""\e[0m"
exit 1
fi
set -o errexit
And if you use -e , you will probably need the default value helper to validate input arguments: # the :- operator means "use the right side value if the left side ($1) is not set"
env=${1:-}
inventoryFile="${baseDir}/env/${env}/inventory"
if [[ -f "${inventoryFile}" ]]; then
echo -e "\e[1;31m""Invalid environment specified!""\e[0m"
exit 1
fi if ! ansible-playbook ... ; then
echo -e "\e[1;31m""Error when executing ansible!""\e[0m"
exit 1
fi
But generally when I need to work around errexit, I tend to add something like " || true" or " || xyz_failed=true" to the end of the command line instead of turning it off and on again.Does all the same with more commands and better error handling.