On Mon, 8 Jul 2024 at 14:42, Oğuz <oguzismailuy...@gmail.com> wrote:
> On Monday, July 8, 2024, Martin D Kealey <mar...@kurahaupo.gen.nz> wrote:
>>
>> It's not possible to change "${BASH_SOURCE[@]}" without breaking some
>> existing code,
>>
>
> It's worth breaking existing code in this case.
>
The only things that the shell has going for it is that it's widely
deployed and stable over the long term.
Otherwise it's a terrible language, and any sane programmer should avoid it
entirely:
- its syntax resembles no other language, with fun quirks such as
intentionally mismatched brackets;
- its lexical tokenization depend on at least 5 different quoting styles;
- text may or may not be evaluated as a numeric expression, based on
flags set elsewhere with dynamic duration;
- text may or may not be split into "words" based on delimiters set
elsewhere with dynamic duration;
- text may or may not be globbed into matching filenames, yet again
depending on a dynamic switch;
- lifetimes for different kinds of entities are controlled by 3
different overlapping scoping rules;
- processes are classified and grouped in arcane ways, leading to the
current complaints about the lifetime of output command substitutions.
If you take away stability then existing code breaks. When that happens
enough times, people get fed up and either rewrite the code in another
language, or completely replace it with a different project. When that
happens enough, there's no point including Bash in the base set for a
distro, so it's no longer universally available.
This has already been happening, and Bash is >this< close to become an
irrelevant historical footnote.
If you modify Bash in ways that are not backwards compatible, you're then
writing in a new language that no new project is likely to adopt.
which leaves us with some kind of explicit opt-in such as:
>>
>
> `shopt -s compat52' should suffice to opt out of the new default. No point
> in making it more complicated than that.
>
That is how we got into the current mess: by assuming that "someone" will
go around and adjust all the already-deployed scripts, by adding a
"compatNN" option that did not exist when the script was written.
For example, I have a Ubiquiti ER-X router, as do several of my friends and
family.
This device has Bash supplied by the vendor. If the vendor ever pushes a
future version of Bash with breaking updates, even though they will have
fixed *their* scripts, my internet connection will die before I find out
that I need to patch the scripts I've installed in it. And then I have to
go track down the other people who've installed copies of my scripts, and
get them to update them (which will be difficult if it has broken their
internet).
That's what "worth breaking existing code" costs in reality: other people's
stuff breaks when they've had zero advance notice, because they aren't the
people deciding to upgrade Bash.
-Martin
PS: this situation would be somewhat ameliorated if it were possible to use
shopt -s compat$CURRENT_BASH_VERSION, so that it won't need modifying to be
compatible with a future release of Bash. Having to wait until the next
version of Bash is released before it can be patched to say what version it
needs is cruel.
PPS: In my opinion, the only hope for Bash to continue to exist in the long
term is for it to either:
(a) absolutely guarantee stability, forsaking *all* new features; or
(b) adopt a full suite of features that make it into a "normal" programming
language, including: support for modules written for different versions of
Bash to safely cohabitate in a single script; lexical scoping with
namespaces; being able to store references in variables, including some
kinds of handles for filedescriptors, functions, processes, and process
groups; some mechanism to perform rewriting during parsing (going well
beyond what aliases can do) so that new features can be proposed and
implemented in shell before being implemented in the C core. And all of
that while not breaking code that doesn't ask for these new features.
