Re: Regression in pattern substitution with compat42

[Martin D Kealey]

On Tue, 14 Feb 2023 at 01:00, Chet Ramey <chet.ramey@case.edu> wrote:

In this case, the behavior is controlled by an option. You just don't like
> the default setting.
> We had this exact same discussion back in November.
>

Too right I don't like it, and the previous discussion was wholly
unsatisfactory.

I do not understand why it is considered acceptable to add new features at
the expense of breaking existing scripts when the breakage is so clearly
unnecessary.

(In this case, for example, a new micro-localised special parameter could
have avoided breaking existing valid scripts, and as a side bonus, would
have avoided re-parsing nested expansions.)

I support one release at a time -- the current one. The distros do what
> they do.


My point is not to introduce a new development stream. Quite the contrary,
I'm trying to narrow down what needs to be supported.

As it stands, every release of Bash that's ever been made is equally
"valid" for all time. Which means that after declaring some minimum version
of Bash for our script, we're obliged to make it work on every subsequent
version.

I would like to stop adding to the burden for script writers.

There are still Linux versions shipping with bash-4.2, which was released
> in 2010.
>

Is anyone surprised by this, when new versions cannot be trusted?


> I do not have the capacity to support all of those.
>
> > PS: the current "beta testing" arrangement seems to me to have too few
> > participants by at least two orders of magnitude. We need to encourage
> > "bleeding edge" Linux distros and similar to offer pre-built alpha and
> beta
> > releases of Bash.
>
> All the bash testing releases are public, and announced here and other
> places. I don't have the time or energy to chase the distros urging them
> to test releases -- it's hard enough to get the translation project to
> react to testing releases.
>

I've been saying "we", not "Chet". We, the whole community, need to do this.

> compat51 ... since it's a breaking change to previous behaviour?
>
> That's not what the compat mode is for. It's intended as a temporary
> stopgap for things that change between releases -- bug fixes or whatever --
> when there's no other way to control that behavior, and gives people an
> opportunity to fix their code.
>

If that's all that it's "for" then there's a gaping hole in the language
that needs filling.

How does a coder write a script now, and have some reasonable guarantee
that it won't break when Bash 5.3 comes out?

"Temporarily add «shopt -s compat52» when Bash 5.3 is released" is
mind-numbingly wrong-headed.

The "opportunity to fix their code" simply does not exist for a sizable
proportion of scripts, where there's no formal distribution process, no
maintainer, no support, and no coding competence in the end-user.

The shell is a god-awful mis-designed language from almost every vantage
point. The ONLY thing going for it is its putative stability.

In languages like Perl or Go, all breaking changes need to be explicitly
turned on, either by requesting individual features, or by declaring a
minimum version that has all the required features. All other 'new'
features remain turned off.

If I can't convince you of the vital importance of this, then I give up...

So if I make "Bash6" as a fork of Bash 5.1, with the following guarantees,
would anyone be interested in adopting it?

   1. Changes are only enabled when explicitly requested. (We don't guess
   ahead of time which changes will break something.)
   2. An approved list LTS releases (selected from previous releases, not a
   separate development branch), and expiry dates for other (interim) releases.
   3. Document expectations for distros, including:
      - Install with version numbers in filenames (same approach as used
      for ELF shared library numbering in Linux and elsewhere), with
symlink for
      just "bash";
      - Only install LTS releases in embedded devices or where the user
      cannot manage software updates;
      - Encourage users to install multiple version, especially all LTS
      versions;
      - If /bin/. exists in your distro, ensure that /bin/bash and
      /bin/bash$version are (or are symlinks to) the relevant versions.
   4. Allow scripts to declare the minimum required Bash version (as
   command-line option so it can go in #!)
   5. Allow scripts to declare the maximum tested Bash version (the
   "current version" when they're written). This would have a permanent
   effect, unlike the current shopt compat, which requires editing when one
   later discovers breakage caused by deployment of a future version of Bash.
   (Most likely I would just expand "shopt compat" by including "compatXX" in
   release XX, and not delay it until the next release.)
   6. Implement new features as non-breaking changes where possible, or
   "least surprise" if not. New variables only in a predefined namespace
   (probably BASH_* but I'm open to suggestions at this point).

Conversely, there are some ancient features I plan to stop supporting,
especially C compilers prior to C99.

I would like a planning discussion for general future directions,
preferably taking Bash towards a regular language, with POSIX compliance
and "old Bash" compliance as shims.

If we're just going to accept breaking changes willy-nilly, we make a lie
of that stability. If we're not going to compensate by making linguistic
and structural improvements, then in my opinion the only honest thing to do
is to shut down the entire project: Bash 5.1 should be the last ever
release.

-Martin