Bash is about pipelines which is a rather functional concept. If you can exploit these you can write succinct, readable and effective bash IMHO. If you're just stringing together a lot of conditionals it gets ugly fast.
There isn't such a thing as readable bash, as a significant amount of its syntax is symbolic (and cryptic, by the way), and it's full of warts and unintuitive quirks.
Writing very simple scripts is certainly simple, but anything even a bit functionally more advanced (arrays, but even strings cycling or splitting is quirky) is a pain. Heck, even something as simple as process substitution is horribly unsafe (I wonder how many devs know how/why).
It's practically impossible to write correct Bash without shellcheck.
I disagree that bash needs to be cryptic, but I've also written perl code, so maybe any resemblance of a sane perspective was beaten out of me.
> It's practically impossible to write correct Bash without shellcheck.
I agree with this, since I've never seen a bash script, in the wild, that passed the important bits of shellcheck, without already being passed through spellcheck. I challenge anyone that thinks they've written good bash, with any significant level of complexity, to run that script through shellcheck. Each time I've done this, when starting at a new company, the response has usually been "Will not fix. That's why you don't use spaces in filenames/paths".
But it's not a developer's choice - Bash's syntax is cryptic itself. Here's a random sampling of common patterns:
Arrays:
- `${#myvar[@]}`: unreadable
- `mapfile myvar < <(grep pattern file)`: "mapfile" is not exactly a clear term (there's the synonym
"readarray", but "mapfile" is the reference; worse, you may find both used inconsistently); the
command as I wrote it also has two problems
Strings:
- `${myvar##.*}`: unreadable
- `echo $(IFS=,; echo "${myvar[*]}")`: unreadable; most also don't know the difference between `[@]`
and `[\*]`; this doesn't also work for two-char join operations
- `[[ $myvar =~ $(echo '\bpattern\b') ]]`: unreadable, and most don't know why command substitution
is needed
Redirections:
- `3>&2 2>&1 1>&3`: most don't know what this means
One can certainly get an idea of what's going on; but one gets an idea of what's going on also when reading assembly with labels.
