Busybox/coreutils/the userspace of your platform are the "standard library". The shell is basically just there for control flow and IO, everything else is just programs on your computer.
The shell has a ____wide____ userbase with many kinds of users. Depending on your goal, the rabbit hole can go very deep (how portable across interpreters, how dependant on other binaries, how early can it work in a bootstrap scenario, etc).
Would it really be worth the effort? When this level of complexity is reached, I personally think it’s better to use a more capable language, such as Python or Ruby.
Not only that, but the strength of bash is its ubiquity. (Or for that matter, posix sh, if you want even more ubiquity.) If we started adding lots of features to bash, it wouldn’t make sense to use them unless you are positive every place using your script has a new-enough version installed. Which defeats the purpose of the main use case for bash in the first place, which is (IMO) for portable scripts that will run on any Unix-like system.
Neither Python nor Ruby offer a simple interface to concurrency, serialization and terseness. Not even close. And aren't moving in the desired direction. Perl could have tried... but it's a separate can of worms, and still not quite there.
PowerShell is a missed opportunity. A project with a ton of resources dedicated by a company with bottomless coffers... which ended up being sub-par.
I wish there was a sensible alternative, but I haven't found one yet.
POSIX and the Single Unix Specification are pretty much all you have
I write a lot of shell scripts and they tend to be POSIX-compliant. For dependencies, you can use the `command` command to fail elegantly if they're not installed.
"builtins" are primitives that Bash can use internally without calling fork()/exec(). In fact, builtins originated in the Bourne shell to operate on the current shell process, because they would have no effect in a subprocess or subshell.
In addition to builtins and commands, Bash also defines "reserved words", which are keywords to make loops and control the flow of the script.
Many distros will ship a default or skeleton .bashrc which includes some useful aliases and functions. This is sort of like a "standard library", if you like having 14 different standards.
'[' is an external binary in order to catch any shell or script that does not interpret it as a builtin operator. There may be a couple more. Under normal circumstances, it won't actually be invoked, as a Bash script would interpret '[' as the 'test' builtin.
Every time I learn a new Bash trick or quirk, it just pushes me further towards Powershell and Python for system administration.
Bash scripts are so hacky. With any other language, my though process is "what's the syntax again? Oh right.." but with bash it's "how can I do this and avoid shooting myself in the foot?" when doing anything moderately complex like a for loop.
Is there an attempt anywhere to build a slightly modern standard library for bash scripts?
You know besides stack overflow?