Here is something related from 2021 that also touches on bash's [[ operator and that I think you might enjoy in this context: https://jmmv.dev/2021/08/useless-use-of-gnu.html
In some non-bash shells, the `function` keyword is needed to declare certain types of function.
For make `$(shell)`, if you're building a lot of targets the performance difference can be measurable. Still, it loses in the nop case, so you should actually usually do `include` to trigger re-making.
GNU is completely right to ignore POSIX, since POSIX is not useful for solving most real problems.
In shells that aren't POSIX-compliant [0], maybe. In which case: yes, there are many wildly different scripting languages with REPLs.
[0] https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V...
POSIX, being a standard that can be tested, is at least a specification or agreement that can be met by multiple products to enable them to interact
For scripts though, sticking to POSIX sh often makes sense, yeah. You should at least be aware if you use of Bash-isms.
What it doesn't explain is why a Linux user should much care about portability. OpenBSD and FreeBSD are alive and well, but the number of users seems so small that they aren't a particular concern. Maybe you could argue that we "should" consider these OSes out of a sense of fairness, but where does that stop? Do I also need to consider something obscure like vxWorks?
BusyBox (Alpine) is more interesting, but the changes there are so significant that a port will almost always be needed anyway.
Are there other compelling reasons to care about the non-GNU ecosystem?
----
What I'm trying to say is that open standards (and the portability that comes with them) is not something that just happens on its own. It takes active maintenance, and part of that maintenance is opting to adhere to the standard even when it would be more convenient to use extensions available in the most popular systems.
Will you personally suffer from liberally using Bashisms? Not in the first order. But if we encourage that sort of thinking as a rule, the standards become meaningless. I believe that would be a net negative change for the world, but there are many intelligent people who would disagree.
From my PoV it is generally portable anyway: almost everywhere I use a shell of that nature bash is present. The exceptions to this are things that need to run in small environments, like anything which may end up in initrd (where busybox us generally providing shell/script support).
Though I do wish people would make sure they specify bash in the #!/bin/bash in scripts unless trying to stick to the standard, as using #!/bin/sh causes problems when extensions are used and something lighter than bash is the default script runner (i.e. dash in Debian, and again busybox commonly in small environments). Only use #!/bin/sh if you lnow you are making an effort to be compliant.
This is the best argument I know in favour of not standardising, and the danger is not the direct consequences, but rather than our expertise in the standard atrophies when we do most of our work outside of it, which means our public work suffers too.
Also sometimes the private goes public and then who's gonna fund redesigning it in the standard? That rarely happens.
> From my PoV it is generally portable anyway: almost everywhere I use a shell of that nature bash is present.
Much like Internet Explorer 6, you mean.
A key difference is that bash is not claiming to be standard where it is not. It implements the full standard as well as its own extensions. It does not do standard things wrong¹ in order for its extensions to work².
I see posix-sh/bash more like javascript/typescript than good-browsers/internet-explorer. Which makes me wonder: is there a gnu/bash->posix/sh converter out there…
--
[1] well, there are a few oddities, like == behaviour in test which can cause portability issues because the standard doesn't specify that and people might accidentally use it when trying to be as portable as possible, but this also affects sh so is a general environment issue not specifically a bash related one. Also that doesn't break standard portable behaviour.
[2] or in the case of IE, doing standard things wrong, and its own extension wrong between versions too!
I actually feel triggered.
That was such a nightmare period in my web-dev career (pretty much the entire 2000's), it pretty much singlehandedly pushed me to find backend work as much as humanly possible
The dash shell is small and fast, but it does not allow any bash/korn language extensions beyond what was recorded in the POSIX.2 standard in the early 1990s.
Linux users should care because the Debian/Ubuntu family use dash as the system shell, so this problem is very real as many have learned.
> the number of users seems so small that they aren't a particular concern. Maybe you could argue that we "should" consider these OSes out of a sense of fairness, but where does that stop?
This is the same argument that many companies and products have made over the years (and still do at times) for ignoring Linux. To have a Linux user use that same argument against OSes with even smaller userbases is kind of amusing to see.
if [ a = b ] || grep -q ^hello$ /usr/share/dict/words; then
echo "test failed and grep succeeded"
fi
Isn't that normal everyday shell use?
(And I might quote '^hello$' personally just on principle for having special chars, especially dollar, and to help syntax highlighters.)
Tangential, but your blog software seems to have mangled the headings; it's serving eg:
make $(shell …) expansion
make $(shell ...) expansion
<h1 id=make-shell--expansion>make $(shell …) expansion</h1>
(Note: iOS probably displays … as U+2026 "…", which often looks identical to "...", but is actually a single non-ASCII character.)
I assume there's some semantic reason in which each is appropriate. I don't know what it is and am curious though!
> Special cases aren't special enough to break the rules.
> Although practicality beats purity.
:)