Apropos the intentional breakage of ((10#$X)) I wrote (back in June 2023): > > Is there any chance this can be reversed before it becomes an official release? to which Chet replied: > This happened years ago.
I have to admit that I'm finding that being a maintainer for a large suite of Bash scripts is a very frustrating experience because Bash keeps shifting under me. Many (perhaps most) script maintainers don't hear about a change until several years after it's incorporated into an official release of Bash, because that's how long it takes for it to percolate through several tiers of release processes and actually get installed. We test our scripts for backwards compatibility when we make changes, but most of us don't have automated systems to check for *forwards* (or *anticipatory*) compatibility. This is especially problematic when combined with "every release of Bash is valid forever". Without the ability to firmly say "ooops, that version of Bash was broken, everyone please stop using it", this makes for a terrible experience for maintainers of scripts that then have to run where someone has chosen the version of Bash that's available. If there's a bug tracking system beyond "threads in a mailing list", I'd like to know how I can get access to it. The "roadmap" seems to consist of Chet occasionally announcing that some refactoring has been done or is in progress; if there's a list of future plans somewhere, I'd love to see it clearly published. Bug triage seems to consist of a day or so's discussion in this list, but when a solution is proposed it usually gets little or no discussion, and no code review whatsoever; often we only get "this will be fixed in [an upcoming] release", with no mention of *how* a problem will be fixed. There's nobody actively canvassing users, asking "will this [insert detailed proposal] break your code?". And no, telling this mailing list is NOT enough, because this list is unrepresentative of maintainers of Bash scripts and other Bash users. (About now Chet is shrugging his shoulders and saying "what else can I do". The fix for that is not to have the whole project crammed into one human's brain. And yes, I do volunteer to help sort this out.) (Aside: even as an "experienced" Bash user, I didn't join this list until relatively recently because I was under the impression that it was only for people who actually *fixed* the bugs in Bash, not merely complained about them. A key reason I believed this was because this list is the target address for the "bashbug" reporting script. Perhaps this list should be renamed "bash-testers", if that's its true purpose.) End-of-life dates for previous versions should be promulgated as soon as possible. I have my own idea of what they should be, but I'd like to hear *how* other people would choose their dates. When I said: > > This change will break scripts that use $((10#$somevar)) to cope with > > somevar having leading zeroes OR BEING EMPTY. Chet replied: > this clearly invalid syntax "Clearly Invalid" is a matter of perspective. To me "no digits at all" is the MOST logical way to write value zero, being the logical result of "remove leading zero digits". (I may be sufficiently atypical that nobody on this list agrees with me, but I'm definitely not unique globally.) That change introduced an inconsistency into Bash: X= ; ((X == 0)) # true X= ; ((10#$X == 0)) # was true, now broken I liked it better how it was. (From a language design point of view, the only practical limitation to treating an empty string as numerically zero is that an empty string needs to be a recognisable lexical token; this is not the case in human languages, which is why we write "0" instead, but happily in most computer languages an empty string is indeed trivially differentiable from the absence of any token. Bash is the exception in that $x may expand to one, many, or no tokens, depending on context, but in *this* context it's clear.) Chet said: > You might be interested in the discussion: > https://lists.gnu.org/archive/html/bug-bash/2018-07/msg00015.html > https://lists.gnu.org/archive/html/bug-bash/2019-06/msg00039.html I read that and wept. Just because someone didn't understand the difference between a single token and an entire arithmetic expression doesn't mean "change the definition of a token" was the right response. (What I really don't get is why were they trying to use an explicit decimal radix on something that was the result of a previous arithmetic expansion, and therefore already guaranteed to be decimal?) Even if this seemed to be clearly the reasonable response, why was there no clear & separate solicitation of feedback for "we propose to invalidate "10#" without any following digits"? >> However, a somewhat similar situation with hex prefix, > >> 0xDIGITS, still allows just "0x" as a valid zero constant. > >> > >> Not sure whether this should be considered a bug, > >> and whether it's worth fixing - just letting you know. > >> > > > > No, definitely not. It's established behaviour, and should not be removed > > without an explicit shopt. > > It's clearly a bug -- it's an invalid C constant. I suppose we can call it > an extension. > "Clearly a bug" is a matter of opinion, especially when this old behaviour creates no security vulnerabilities and conflicts with no historical, existing or proposed syntax. Like all extensions that people are actually using, it should not have been gratuitously removed. I've been a stalwart supporter of Bash for 30 years, and I've recommended it ahead of zsh because its POSIX support is better. By now the only point in using Bash is either its full POSIX support, or its commitment to long term backwards compatibility. Clearly I'm been wrong about the latter. Sometimes there is a compelling valid case for changing behaviour that is a security nightmare, but rarely, and "this is obviously a mistake" has repeatedly been the weakest of cues for a wrecking backwards compatibility. Just because the hundreds of people on this list can't think of a valid use for some "mistake" does not mean that among the millions of users nobody else has found one. Chet please tell me, after 30 years of me using Bash, why should I use Bash for anything, if what I write now is going to break in 5 or 10 years? Lately I've struggled with my conscience when I've recommended Bash as the shell of choice for new users; perhaps should I be campaigning to kill off Bash entirely? -Martin
