I've been writing Bash scripts (among other things) professionally for 15 years and I didn't know (and had never seen used) most of those tricks: read -d'', printf %q, @Q, all those -z options, and even realpath.
Bash and other shell scripting makes simple data manipulation (filter/map/reduce/groupBy...) a royal pain in the butt and something incredibly hard to get right, without introducing horrible bugs under the surface of your script.
The underlying reason is that shells were born as human interfaces for the basic UNIX calling convention for processes (ARGV and return code) and their input/output ports (byte-based stdin/stdout) both of which are hopelessly inadequate to represent even the most basic data structures, and thus need convoluted rules in place to be of any use (see the getopt conventions, including the double dash, and all the CSV-like input/output formats, including newline- and zero-terminated arrays of strings.)
Take the example of command arguments: as the article points out, mixing options and argument arrays into the same flat array of strings (ARGV) is a recipe for disaster. Compare it with the calling convention in any modern programming language, where an array of filenames is a single well-defined item, and a boolean flag or other option is a completely different item.
Couple this shaky foundation with the complex escaping and interpolation rules added by shells to make it useable by people (single and double quotes, backslashes, dollars, globs... nest and repeat, nest and repeat...) and you get a house of cards built on sand.
The only redeeming quality of Bash and UNIX in general is that it's very easy to write something that works most of the time. Whether you want to write something flaky like that to "get the job done," or something that will work reliably all the time, hopefully with no security flaws or other bugs lurking under the surface, is up to you.
Personally, I'll be phasing out my Bash usage more and more, in favor of strongly typed languages, even to do "scripting" tasks. I will also be looking more at PowerShell, which was designed to solve this very problem and which I have ignored for too long.
Bash and other shell scripting makes simple data manipulation (filter/map/reduce/groupBy...) a royal pain in the butt and something incredibly hard to get right, without introducing horrible bugs under the surface of your script.
The underlying reason is that shells were born as human interfaces for the basic UNIX calling convention for processes (ARGV and return code) and their input/output ports (byte-based stdin/stdout) both of which are hopelessly inadequate to represent even the most basic data structures, and thus need convoluted rules in place to be of any use (see the getopt conventions, including the double dash, and all the CSV-like input/output formats, including newline- and zero-terminated arrays of strings.)
Take the example of command arguments: as the article points out, mixing options and argument arrays into the same flat array of strings (ARGV) is a recipe for disaster. Compare it with the calling convention in any modern programming language, where an array of filenames is a single well-defined item, and a boolean flag or other option is a completely different item.
Couple this shaky foundation with the complex escaping and interpolation rules added by shells to make it useable by people (single and double quotes, backslashes, dollars, globs... nest and repeat, nest and repeat...) and you get a house of cards built on sand.
The only redeeming quality of Bash and UNIX in general is that it's very easy to write something that works most of the time. Whether you want to write something flaky like that to "get the job done," or something that will work reliably all the time, hopefully with no security flaws or other bugs lurking under the surface, is up to you.
See Worse is Better and the New Jersey approach that spawned C, UNIX and ultimately Bash: https://www.jwz.org/doc/worse-is-better.html
Personally, I'll be phasing out my Bash usage more and more, in favor of strongly typed languages, even to do "scripting" tasks. I will also be looking more at PowerShell, which was designed to solve this very problem and which I have ignored for too long.