But seems to want us to replace the old reliable shell with it (Or this is what I understand). I see a lot of people reinventing the wheel in Linux and trying to appeal the new users. What you have in the end is normally worse than the standard ones. Is just dissecting Linux in a lot of smaller particles and smaller rooms.
So thanks, but not thanks. Not to me.
Wouldn't be much more practical to use all of those talent and ideas to help to improve the extant bash shell instead?
There are lots of "old reliable shells" that are POSIX incompatible. (t)csh[1] is the first family that comes to mind.
The EEE analogy is more applicable to GNU Bash anyways: it extended the POSIX sh baseline with a bunch of GNUisms that a lot of "POSIX" sh scripts now unintentionally use.
I do not think that there are many GNUisms in bash, even if indeed there are a few optional syntax variants that should be avoided for compatibility with other shells.
In any case I am not aware of any GNUism that is actually useful in scripts, so taking care to not use any syntax variant specific to bash is not a problem.
All the important bash features that are not POSIX are not GNUisms, but they are:
1. The 50% of the new ksh 1988 features that have not been included in the POSIX shell, e.g. condition testing "[[ ... ]]" and arithmetic testing "(( ... ))".
2. All the new features added by ksh 1993, none of which have been included in POSIX, e.g. "for (( ... ))" and the extra parameter expansions that replace the most common invocations of sed or awk.
3. The brace expansion from csh
4. The extended brace expansion forms added by zsh (which generate arithmetic progressions and are usually preferable to "for ((...))")
Attempting to write POSIX-compliant scripts in 2021, i.e. not using these extra ksh/csh/zsh features provided by bash, is a huge mistake in my opinion, because without these features any non-trivial script becomes much longer and much more error-prone.
The Google recommended style for shell scripts (https://google.github.io/styleguide/shellguide.html), which is based on using all bash features, is pretty decent. It is far less work to ensure that bash or ksh/zsh exists on any target system than to maintain any obsolete POSIX-compliant scripts (which are stuck to the 1979 Bourne shell features + only half of what ksh 1988 has added).
To the best of my knowledge, Bash’s parameter expansion syntax[1] is entirely an original, non-POSIX GNUism. It’s extremely common and useful in scripting.
No, all the kinds of parameter expansion that exist in bash belong to 3 groups:
1. expansions introduced by the Bourne shell in 1979
2. expansions added by the Korn shell in 1988 (e.g. ${parameter#word} and ${parameter%word})
3. expansions added by the Korn shell in 1993 (e.g. ${parameter:offset:length}
and ${parameter/pattern/string})
There are no parameter expansions that have been introduced by bash.
I agree that the parameter expansions introduced by ksh93 are extremely useful in scripts.
The fact that they are not compliant with POSIX is a good reason to ignore POSIX compliance.
The POSIX compliant way is to use sed for substitutions and awk for substrings (even expr is not POSIX compliant), which results in much longer expressions in which it is easy to make mistakes, and in slower scripts, because external processes must be executed even for simple string expressions.
There are a lot of uses for "@", most of which come from Bourne sh or from ksh.
I assume that you refer to the "${PARAMETER@OPERATOR}" type of parameter expansion, which is mostly used to either replace invocations of tr for character conversions or to provide quoted strings.
You are right that this kind of parameter expansion is specific to bash and I was wrong when I have said that there are no bash specific parameter expansions. "${PARAMETER@OPERATOR}" is the only exception that was introduced by bash and which has not been taken from the Bourne or Korn shells.
I have forgotten about it, because I do not use it, precisely because it is the parameter expansion variant that is provided only by bash.
> Wouldn't be much more practical to use all of those talent and ideas to help to improve the extant bash shell instead?
Yeah, good luck with that.
It's a garbage pile of code that creates an interpreter with piles upon piles of undefined behavior that random scripts out there in the world rely on.
I don't even think it was a working CI setup.
I'd be super glad to be proven wrong, maybe things have changed in the meantime.
