What I always find frustrating about that, is that even a colleague with much more Bash experience than me, will ask me what those options are, if I slap a set -euo pipefail or similar into there.

I guess, I could prepare a snippet like in the article with proper comments instead:

set -e # exit on error
set -u # exit on unset variable
set -o pipefail # exit on errors in pipes

Maybe with the whole trapping thing, too.

But yeah, will have to remember to use that. Most Bash scripts start out as just quickly trying something out, so it’s easy to forget setting the proper options…

When to use what

My advice is to optimize for read- and understand-ability.

This means to use the || operator when the fallback/recovery step is short, such as printing an error or exiting the program right away.

On the flip side, there are many cases where an if else statement is preferred due to the complexity of handling the error.

Fully agree. Shell scripts quickly get ugly over 50 loc. Please avoid spaghetti code in shell scripts too. The usual

if [ -n "$var" ]; then
    xyz "$var"
fi

is ok once or twice. But if you have tens of them,

[ -n "$var" ] && xyz "$var"

is more readable. Or leave the check entirely away if xyz reports the error too.

And please.do.functions. Especially for error handling. And also for repeated patterns. For example the above, if it’s always xyz, then something like

checkxyz() { [ -n "$1" ] && xyz "$1"; }

checkxyz "$var1" && abc
checkxyz "$var2" && 123
checkxyz "$var3 || error "failed to get var3" 2

is more readable.

And sometimes, a function is better for readability, even if you use it only once. For example, from one of my bigger scripts (i should have done in python).

full_path() {
  case "$1" in
    /*)  printf "%s\n" "${1%/}";;
    *)   printf "%s\n" "$PWD/${1%/}";;
  esac
}
sanitize() {
  basename "${1%.*}" \
    |sed 's/[^A-Za-z0-9./_-]/ /g' \
    |tr -s " "
}

proj_dir="$(full_path "$proj_dir")"   # get full path
proj_name="$(sanitize "$proj_dir")"   # get sane name

Code as documentation basically.

Right, about the last point: if your script grows over 200 loc despite being nicely formatted and all (if-else spaghetti needs more space too), consider going further in a real programming language.
Shell is really only glue, not much for processing. It quickly gets messy and hard to debug, no mather how good your debugging functions are.

EXCELLENT Article!

Now interested in Notifox, that person’s pet-project, too…

( :