Re: Regression in pattern substitution with compat42
On Wed, 15 Feb 2023 12:48:10 +1000 Martin D Kealey wrote: > > 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? It is, perhaps, telling that two of the most notable rolling Linux distributions continue to hold off from issuing 5.2 in their stable channels. That includes Arch, the very same Arch that routinely performs same-day releases from upstream without any semblance of QA - including for glibc - and generally doesn't bother to backport any critical fixes between upstream releases. > So if I make "Bash6" as a fork of Bash 5.1, with the following guarantees, > would anyone be interested in adopting it? > It seems like a lot to take on but count me in as being interested. -- Kerin Millar
Re: Regression in pattern substitution with compat42
On Tue, 14 Feb 2023 at 01:00, Chet Ramey 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
Re: Regression in pattern substitution with compat42
On 2/9/23 5:32 PM, Martin D Kealey wrote: 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? 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. 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. 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? I support one release at a time -- the current one. The distros do what they do. There are still Linux versions shipping with bash-4.2, which was released in 2010. 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. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: Regression in pattern substitution with compat42
On Fri, 10 Feb 2023 11:32:54 +1300 (NZDT) Martin D Kealey wrote: > 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? Somewhat related is https://bugs.gentoo.org/881383. -- Kerin Millar
Re: Regression in pattern substitution with compat42
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.
Re: Regression in pattern substitution with compat42
On 2/8/23 1:50 PM, Tom Briden via Bug reports for the GNU Bourne Again SHell wrote: Bash Version: 5.2 Patch Level: 15 Release Status: release Description: As of version 5.2-beta, replacing a single backslash with a double backslash is no longer possible when using BASH_COMPAT=4.2. The issue appears to have been introduced in commit https://git.savannah.gnu.org/cgit/bash.git/commit/?h=devel=2a1c81bf634d372fde5141d7e616042ca960d9b4 which now returns `1` from `shouldexp_replacement`. shopt -u patsub_replacement -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
