On 8 Feb 2023 at 18:50Z Tom Briden wrote: > Bash Version: 5.2 > Patch Level: 15 > Release Status: release > > As of version 5.2-beta, replacing a single backslash with a double backslash > is no longer possible when using BASH_COMPAT=4.2.
On 9 Feb 2023 at 15:57Z Chet Ramey wrote: > shopt -u patsub_replacement Surely that should be automatic with compat51 and earlier, since it's a breaking change to previous behaviour? Sometimes mis-features like this make their way into public releases of Bash, and it seems to me that there needs to be a way of saying "sorry, that release was a mistake, don't use it", rather than every script from now to eternity having to cope with potentially being run under this broken version of bash. In other projects this is done by having two release streams, "LTS" for long term support, and "standard" with a relatively short end of life, typically 6-24 months. (And yes sometimes a new short term version is released that has no changes from the previous one except a new expiry date.) Is there any chance that we could get a scheme like this for Bash, where standard releases come with a "don't use after" date, so that script writers don't have to cope with broken versions potentially remaining forever? -Martin 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. PPS: personally I would go as far as emitting a warning message after a cut-off date, otherwise people will find some excuse to ignore the installation instructions. PPPS: I'd be happy to work up a patch to implement this latter suggestion.
