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.

I like using bash a lot for terminal automation but as soon as anything goes beyond around 7-15 lines I reach for a scripting language like python or js. Bash is just really hard and counterintuitive

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…

EXCELLENT Article!

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

( :

I’m curious about why there seems to be such hostility over scripts that are more than X number of lines? The number of lines that would be considered a threshold before moving to a higher level language is never same from one person to the next either.

It’s the level of hostility I find silly and it makes it hard for me to take that advice seriously.

Let me just drop my materials for a talk i’ve given about basically this topic: https://codeberg.org/flart/you_suck_at_shell_scripting/src/branch/main/you_suck.md

Mainly because: The linked article is all nice and dandy, but it completely ignores the topic of double brackets and why they’re nice.

And also, and this is my very strong opinion: if you end up thinking about exception handling (like the mentioned traps) in shell scripts, you should stop immediately and switch to a proper programming language.

Shell scripts are great, i love them. But they have an area they’re good for and a lot of areas where they aren’t.