Best Practices for Writing Bash Scripts

kvz.io

20 points·sleepy_ghost··3 comments

> Avoid using #!/usr/bin/env bash -e (vs set -e), because when someone runs your script as bash ./script.sh, the exit on error will be ignored.

Besides that, it wouldn't work on at least linux. You'd get the error:

> env: ‘bash -e’: No such file or directory

because of how everything after the first space is taken as one argument in the shebang.

> Surround your variables with {}. Otherwise bash will try to access the $ENVIRONMENT_app variable in /srv/$ENVIRONMENT_app, whereas you probably intended /srv/${ENVIRONMENT}_app.

I think using the braces all the time instead of only as needed is an exaggerated solution. The rule of what's parsed as the identifier is pretty intuitive. `_` is a valid identifier character so the identifier continues. I can't see this mistake not being obvious, especially with syntax highlighting. I think adding braces all the time would just add too much syntax-cruft that would obscure important details.

> __base="$(basename ${__file} .sh)"

They forgot to quote the variable expansion there.

I don't agree. Adding braces all the time leads to a more cognitive association of what is the variable. IMHO, this leads to better script writing and ease, in my case, of transitioning to other languages. Not so much because of the braces, but of the context of a variable.

If that makes any sense at all.

<<if [ "${NAME:-}" = "Kevin" ] will set $NAME to be empty if it's not declared >>

The OP probably meant "${NAME:=}" not "${NAME:-}"

Reply on news.ycombinator.com