> try to restrict shell scripts to POSIX semantics

I have to admit, while i admire the idea of and understand the reasoning behind striving for POSIX-compatibility, i never couldn't fully get past viewing this as some kind of hypothetical exercise. The chance that any script i (or presumably most people who get this advice on pages like SO) will ever write will have to run on a 25 years old Tru64 machine or even a modern Mac, BSD, QNX, … is relatively small. Truth is (in my case), most of the scripts will never even run on anything but the system they were written on. As i said, i admire the idealism though.

It is easier than you think.

First, we get rid of PATH= inside scripts. A lot of incompatibilites comes from /bin, not the shell itself. Treat executables like services, rewrite everything (reasonable) in pure shell.

The scenario I'm trying to prevent is "I want to cut a string in OSX but I wrote for a GNU executable and the syntax is slightly different". Most shell one liners can be rewritten as good quality portable code.

If you take just Debian, there are 5 or 6 shells available via apt. These should run wherever Debian runs (x86, arm, hurd, whatever).

You can't write a reasonable JavaScript that runs on JScript.exe (it still exists), Apple JXA, gjs and node.js. But you _could_, the language is stable enough, for long enough, that everyone knows how to feature detect the shit out of everything js related.

For the shell though, we don't even have a solid list of things that work or not in each shell, or differences across core utilities. Something like caniuse.com, but for UNIX shells, not browsers.

Having a page that runs on all browsers was once something impractical and idealistic. Not using tables and invisible 1x1 pixels for layouts was once idealistic. We fixed it though. Mostly.

Many people who write in Bash end up writing in Bash v4, which won't work on a Mac until you install bash from Homebrew. Whereas POSIX just works. If you need to run a script on an Alpine Linux container and didn't install bash, that would be using ash, so again POSIX would work.

But the reason to use POSIX scripting isn't portability, it's simplicity. Simple scripts are just easier to reason about, easier to maintain, and are less prone to bugs. The code might be a little more verbose, but its simplicity still reduces the cost of complexity.

Most people don't realize this until they've been writing scripts for 15 years and realize they can do almost everything with POSIX and that it makes their life easier in the long run. But in some cases what I want to do would really benefit from Bash, so I use Bash then. It's not a hard and fast rule; I switch based on what would work best for that case. It's about balance, compromise, and being flexible.

Many of my scripts run on my computer, but also have to run on Alpine Linux because that's what my employer's CI system exposes. That means Busybox for the common shell utilities (unless the script or job installs something else as needed) and thus POSIX compatibility is important.

>Nobody who has ever used Bash has read the whole manual.

Bold claim and patently untrue because I have read the whole manual.

However:

1) Things you don't use often leak out of your brain at a rate that is absurd.

2) Different versions have different features and there's wide variations between versions on different platforms, you can't actually depend on a lot of bash stuff existing, so instead it's usually better to target POSIX sh

I, too, experience Swiss-cheese-brain.

I once thought I’d solve this by taking notes, organizing a journal, and writing ... Well, it was a manual. That had the same problem as other manuals - too long, not gonna read.

Full circle.

I like making flashcards for myself for new topics that I study, in addition to notes. Of course bash as a whole will not fit on a flashcard, but breaking it into high-level topics. looking through the cards I’ve made helps when I feel the need to brush up on a topic in a general sense before diving deeper.

Despite all this, my brain is still Swiss-cheese.

Your note taking, organizing and writing will have helped you retain a lot more info for a longer period of time. It wasn't wasted effort. Still, there is a such thing as "too much". Higher degrees of success are achieved by regularly evaluating where you are in the "too little" to "too much" spectrum.

> The best guide to using Bash is to read the manual (https://linux.die.net/man/1/bash).

Here's the link to the latest official manual on GNU's site:

https://www.gnu.org/software/bash/manual/html_node/index.htm...

Not everyone has portability as a first-class requirement for their scripts. For 95% of what I write, bash 4 is entirely appropriate.

It's more about simplicity than portability. POSIX is simpler and simpler is better. If what you need is impossible with POSIX, then use Bash. If it's impossible with Bash, then use something else.

> Test POSIX scripts with `bash --posix`. Definitely use Shellcheck.

Except that doesn't disable all bashisms so you end up leaving in bashisms as a result, which is what caused all the issues for debian trying to migrate to dash

A quick ToC for the bash manual: 'man bash | grep ^[A-Z]'

I think that fish is supplanting zsh as the "developer's" shell. Bash is like C though, gonna be here for another century at least.

Careful readers of the manual will find this commentary from the bash maintainers:

  $ man bash | sed -n '/BUGS/,/^$/p'
  BUGS
         It's too big and too slow.

It is at this point that such a reader will discover the reasons behind Debian dash.