Most bash scripts are very brittle because error handling is an afterthought. In this blogpost you'll learn about the easiest ways to gracefully catch and handle errors. Best practices and common pitfalls.
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.
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.
But call it a bash script then! Remember:
#!/bin/shis run by all kinds of shells; consider them POSIX. Bash is#!/bin/bash.Uhm, yes. I noted exactly that as well.
Also bash is not always at /bin/bash :-)
Yeah ok, /usr/bin/env then.
Edit: Or /bin/sh (oold convention) and check for bash.
Well, that won’t work on openbsd (and probably freebsd), because non-default.stuff lands in /usr/local/bin.
For Linux you should be fine though.