As you’ll learn later in this blogpost, there are some footguns and caveats you’ll need to keep in mind when using -e.

I am so glad this article is not following blind recommendations, as lot of people usually do. It’s better to handle the error, instead closing the script that caused the error. I think the option -e should be avoided by default, unless there is a really good reason to use it.

set -e

safeDelete() {
  false

  # Surely we don't reach this, right?
  echo "rm $@ goes brr..."
}

if safeDelete all of my files; then
    : # do more stuff
fi

EXCELLENT Article!

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

( :

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…

If you think you need this you’re doing it wrong. Nobody should be writing bash scripts more than a few lines long. Use a more sane language. Deno is pretty nice for scripting.

Let me just drop my materials for a talk i’ve given about basically this topic: codeberg.org/flart/…/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.

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

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

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.