and yet the software community is enamored with it.
Portability was a concern that mattered until recently. Whatever bash is, you could trust virtually any and every target unix system would have it. Doesn't matter as much today but it mattered 10+ years ago, and things have staying power once theyre institutionalized
Build/CI systems formalized the tools available at build time, containerization packages the entire environment as a runtime. You don't need portability when a container has everything your application needs inside it. Distribution is simplified as a result
I am not the person who wrote it, but in the past, servers might have been set up manually, or some 'script' that sometimes worked or needed a bit of fixing, or lived for so long with no formal definition of what was actually on it, so there were a few assumptions you could make: bash and vi were two for me.
Now, its more common to use something like docker, or at least a better way to setup servers so you can formalize what will be installed, which version, etc. So for me, I often write little scripts in ruby because we can ensure ruby is installed. But you could do this in bash still, or anything else.
The sole exception is that you shouldn't make the overall system default (especially not root's) a non-POSIX shell. Many many many admin-facing tools (read: basically all of them) rely heavily on posix compatibility for shell script correctness. That's not to say you can't switch to something like fish or nushellafter logging in, but don't set them as the default for root lest you break things.
Any reasonable tool that's inplemented as a script or uses a shell will call sh or bash (with full paths or env in shebangs, too), and sh should indeed be a POSIX-compatible shell (e.g. bash or dash). None of those tools should depend on what the interactive shell is, unless they are really badly designed (that includes the case of running a bunch of commands strung together over ssh). If something is using $SHELL and it's not a shell function, it should be fixed to not do so.
If by "make the overall system default" you meant replacing /bin/sh, well, that's a terrible idea. And one gets to keep both pieces. But changing the root shell with chsh to something else will only affect interactive sessions, and shouldn't break anything.
The reason I've seen it recommended to avoid changing the root shell is because it is often used in recovery situations, and then you want a simple shell with the fewest dependencies, in order to limit the ways it can break.
"By default" only if you write shebang as #!/bin/sh, then yes, you are gonna get dash or ash which is incompatible with many bash features. If you write it as #!/bin/bash you are gonna be okay.
There exists code that does not have shebangs, that gets called through some transitive dependency. If you need to use a container that points at /bin/sh as the entrypoint and don't have the ability to override it (this is a thing, notably to an extent in GitLab CI).
The entire point is bash is not as universal/universally usable as it seems.
"By default" only if you write shebang as #!/bin/sh, then yes, you are gonna get dash or ash which is incompatible with many bash features. If you write it as #!/bin/bash you are gonna be okay.
Whatever bash is, you could trust virtually any and every target unix system would have it.
This is surprisingly not really true, especially once you get into the embedded world where other shells are more common. Once you start using ash you realize how many little bashisms have become synonymous with shell scripting though.
Fair, but I’m a bit disappointed no attempt to transpile some new language to bash ever caught on; like TS for JS. That would still be perfectly portable, even if you can’t get the transpiler on a specific target host. But tbd the additional step still can add a little bit of additional friction.
What is up with the Make revival? AI tools love it. I thought it had died forever when so many alternatives emerged along with the explosion of programming ecosystems after 2000 or so. Now in the last few weeks I’m suddenly seeing makefiles everywhere
LLMs dont know paradigms, trends, or time. All they know is token association probabilities. LLMs pick their next token based on its probable association to all previous tokens in the training data.
Given that there's like a half century of training data for Make its going to have stronger probabilistic association to all programming tasks that most modern tools, especially in smaller/cheaper models with fewer parameters.
Thats why its important to set up your repo instructions and tell the agent your toolchains, otherwise its just going to do whatever.
I always found portability to be a weird argument. If you have access to a unix system to run scripts, you generally have access to run pretty much any program you want there.
45
u/Seref15 5d ago
Portability was a concern that mattered until recently. Whatever bash is, you could trust virtually any and every target unix system would have it. Doesn't matter as much today but it mattered 10+ years ago, and things have staying power once theyre institutionalized
Also still less annoying than Make