This page is full of good advice (as opposed to a lot of Bash/Shell instructions online). It’s referred to a lot for example in the #bash channel on Libera.Chat, and in the Exercism Bash track.
Thank you for answering “Why should I pay attention to this, the 1 billionth “bash guide” posted to lobste.rs in the past year.” question. It actually has a lot of useful info.
Note that Greg’s wiki also has a section on set -euo pipefail pitfalls, which was discussed in that other thread.
Personally these days I mostly write Bash for 10-20 line or so CI scripts, often prefixed with set -xeuo pipefail. In that case, where there are few complex constructs and the script is short and easy to audit, it’s fine. However, if for some reason I decided to write a larger program in Bash, I wouldn’t do it.
This page is full of good advice (as opposed to a lot of Bash/Shell instructions online). It’s referred to a lot for example in the
#bash
channel on Libera.Chat, and in the Exercism Bash track.Thank you for answering “Why should I pay attention to this, the 1 billionth “bash guide” posted to lobste.rs in the past year.” question. It actually has a lot of useful info.
Submitted as a contrast with another recent post (with comments here).
See also (by the same people as the linked guide):
Note that Greg’s wiki also has a section on set -euo pipefail pitfalls, which was discussed in that other thread.
Personally these days I mostly write Bash for 10-20 line or so CI scripts, often prefixed with
set -xeuo pipefail
. In that case, where there are few complex constructs and the script is short and easy to audit, it’s fine. However, if for some reason I decided to write a larger program in Bash, I wouldn’t do it.The largest Bash script I’ve written in recent years was just a bit over 200 lines, and I opted against it. Hopefully I’ll never write a longer Bash script than that in the rest of my life, though.
Thanks. The wiki also has separate FAQs on the pros and cons of
set -u
andset -e
.