Re: string substitution broken since 5.2

[Alex fxmbsw7 Ratchev]

that u word
comply to very outdated specs
i did word

bye

On Fri, Nov 4, 2022, 15:26 Martin D Kealey <martin@kurahaupo.gen.nz> wrote:

> I now very much regret not commenting on this proposal during the
> pre-release period, and I apologise for not having done so.
>
> On Fri, 4 Nov 2022, 05:50 Chet Ramey, <chet.ramey@case.edu> wrote:
>
> >
> > The option is enabled by default. If you want to restore the previous
> > behavior, add `shopt -u patsub_replacement'.
> >
>
> I am very disquieted by this pattern of creating breaking changes and then
> saying "just add shopt blahblah to go back to the old behaviour".
>
> This might be justifiable to a fix for a security problem (e.g. array
> subscripting), but *this* is just a nice-to-have feature.
>
> Suggesting that an existing script should be modified implies that scripts
> must necessarily have "maintainers" whose job includes tracking changes to
> the language provided by Bash, or that every piece of software installed on
> a system comes from a single source who can test combinations for
> compatibility.
>
> That is not the world that we live in.
>
> The average user out there has almost zero shell scripting experience, and
> even less competence to diagnose faults in their system. They rely on a
> package manager to install versions of basic utilities like Bash, and
> diligently apply updates to keep on top of security. They also get other
> software from sources who know nothing about them or their package manager.
>
> In this context the reasonable thing to do is to aim for maximal backwards
> compatibility, and only enable breaking changes when a special option or
> command is used.
>
> Can we please have an immediate point release turning this feature off by
> default, and then let's take another look at how this can be done without
> gratuitous breakage of existing code.
>
> -Martin
>
> PS:
> I'm puzzled why a bare '&' was chosen in the first place; that seems to
> provide the maximal likelihood of conflict with existing code.
>
> As an alternative that wouldn't need an enabling option, how about using
> "$BASH_MATCH" or "$&"? (I suspect the latter would be easier to use as a
> marker for a deferred expansion.)
>
> Rather than inserting a modal command or option, one possibility might be
> to use the same mechanism as handles POSIX "sh", and extend it to look for
> a trailing version number, and use that to enable new features.
>