Whew, let's go

> Also note that it isn't just Bash that we'd need to download, but coreutils and other utilities that Bash is really built on top of. We tried to fix a pretty simple bug last year in the Bash installer, and it took two weeks to validate a relatively straightforward, one line change was valid on all the platforms we target. This clarifies a lot of what confused me in TFA. I maintained millions of lines of bash code, some of which is decades old and run into only a single bash incompatibility that wasn't fixable with shopt. On the other hand, incompatibilities in programs bash is running are rampant, particularly between GNU and non-GNU systems (and even within GNU there are more surprises than you might think). The phrase "different bash implementations" was a major red herring for figuring out what you were talking about.

Followup question then: Are you hiring? :) What type of work do you do? (is it "sysadmin-flavored," etc.?)

> but coreutils and other utilities that Bash is really built on top of This really is the problem with bash. It doesn't have a stdlib. Posix tried but didn't succeed in sufficiently standardizing userlands. Bash is friendly and easy to hack on, but hard to manage at scale, for this reason. And this crops up all the damn time when you're working with compiled languages. Nobody wants to have two languages. But if one of your languages is compiled, then nobody wants to write and maintain literally everything in that language. At some point you need scripting. Bash is usually what's reached for. But OSX doesn't ship a recent bash. And your coders are probably running OSX. So you have to write scripts that target ancient bash so the devs can work locally, but also work in the cattle farm. You'll spend lots and lots of time fighting it. Or have ridiculous 'setup' docs that will trip up newbie…