Re: proposed BASH_SOURCE_PATH

[alex xmb sw ratchev]

On Mon, Jul 8, 2024, 10:16 Martin D Kealey <martin@kurahaupo.gen.nz> wrote:

>
>
> On Mon, 8 Jul 2024 at 14:42, Oğuz <oguzismailuysal@gmail.com> wrote:
>
>> On Monday, July 8, 2024, Martin D Kealey <martin@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.
>

good idea i had too , compat current bash ver , to be

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.
>