Too damn verbose and you're assuming bash is at /bin. This will cause problems in nix and other environments where bash should be found on the path instead.

Always, always unless the script is guaranteed to not be portable to other platforms:

    #!/usr/bin/env bash
    ...

▲ jacob2161 2 days ago | parent [-]

You're assuming env is in /usr/bin?

There are real environments where it's at /bin/env.

Running a script with

  bash script.sh

Works on any system with bash in the path, doesn't require that it be executable, and is usually the ideal way to execute them.

I don't really believe in trying to write portable Bash scripts. There's a lot more to it than just getting the shebang right. Systems and commands tend to have subtle differences and flags are often incompatible. Lots of branching logic makes them hideous quickly.

I prefer to write a script for each platform or just write a small portable Go program and compile it for each platform.

I'm almost always writing Bash scripts for Linux that run in Debian-based containers, where using /bin/bash is entirely correct and safe.

Regarding verbosity, most people come to appreciate a little verbosity in exchange for clarity with more experience. Clever and compact code is almost never what you want in production code.

	▲	dijit 2 days ago \| parent [-]
		yeah, I agree with this.. all the work that goes into making it portable makes it much harder to read the script as well in most cases. What I typically do is also have a version check for bash, just to make sure that nothing insane happens. I also tend to litter asserts all about the beginning of the code in my compiled programs to ensure my environment is sane. because if I make an assumption, I don’t want it to land on someone’s head unexpectedly. (especially my own)