I tend to find that shorter, putatively simpler bash scripts are often shorter because they don't do adequate (or, at times, any) checking of error conditions.

I tend to find that shorter, putatively simpler bash scripts are often shorter because they don't do adequate (or, at times, any) checking of error conditions. It is deceptively easy to write a terse shell script when you assume that every command, or pipeline of commands, will work exactly as you expect every time. In practice, even simple operations like "rm", or "mkdir", or even "cd" can fail in new and exciting ways. The blanket use of "errexit" and "pipefail" is really only the bare minimum of error handling; scripts that simply _stop_ as soon as a command exits non-zero are not generally an operable product that somebody unfamiliar with the innards of the system can be expected to work with. It is also unfortunately easy to miss out on putting quotes around expansions, or to get caught out by the somewhat peculiar behaviour of variable scoping in functions. Some improved constructs are available in more recent versions of bash, but if the goal is to be _portable_ (without also shipping your target bash binary) you may not be able to use some or any of them. The bash "language" (such as it is) is antiquated and clunky, because it seeks to be backwards compatible with the rich tapestry of history that is the Bourne shell. A truly robust, operable program written in this environment often does not come out a whole lot shorter (if it is shorter at all) than a program written in another language with better facilities.