On Tue, 12 Dec 2023, 05:56 Zachary Santer, <zsan...@gmail.com> wrote:
> On Mon, Dec 11, 2023 at 9:26 AM Chet Ramey <chet.ra...@case.edu> wrote:
> > Part of the issue here is that distros -- Red Hat, at least -- never
> > upgrade the version of bash they started with. Red Hat will `support'
> > bash-4.2 as long as they support RHEL 7.
> To be fair to the Red Hat people, "my scripts used to work and now they
> don't" is the issue they're trying to avoid, at least within a release.
>
Which is exactly my point about these random changes "because we think it
must be a mistake".
There are users out there that depend on these supposedly-broken features.
It is disingenuous to justify a change on the grounds of "alignment with
the documentation". The manual is not a specification (much less a formal
one), and leaves out a great many things that would be required in the
latter. There are *many* things that are "like" something else, but with
extensions that are unexplained and often completely unmentioned. Moreover,
the manual is huge, and not a tutorial, so most users only consult it when
they already have a problem. (And those of us who do routinely consult it
will perform tests when the manual is unclear.)
The source of truth is the implementation, not the manual, and it is quite
offensive to imply that users are at fault when they don't assume the
reverse. We know there are errors and gaps in the documentation, and so do
the users.
Simply disabling existing behaviours breaks things for people who use them,
and doesn't actually "fix" scripts that are already broken. (Those scripts
may get a better explanation of why they're wrong, but they don't magically
start working as intended by their authors.)
It's backwards to suggest that bare "0x" should be prohibited because the
man page says so. The words “Integer constants follow the C language
definition, without suffixes or character constants” were not added to the
manual until June 2019 in the Devel branch (as commit
48492ffae22d692594757e53fb4580ebb1f506cf), and did not land in the Master
branch until December 2020 (as commit
8868edaf2250e09c4e9a1c75ffe3274f28f38581). Ubuntu LTS users would then have
first had a chance to read them in April 2022.
It is not reasonable to expect users to notice that this one line had been
inserted into the manual page but without any actual change of behaviour,
and then to be told 5 years later that NOW our scripts are wrong because
they don't match the man page.
If behaviour is going to change, it should be announced in advance, as a
preface to the change log. Then at least users will have a chance to find
out about it before it bites them, and perhaps provide feedback that such a
proposed change would be undesirable.
So please:
* EITHER change the man page to match the behaviour (I suggest removing the
words «without suffixes or character constants» and substituting «except
that no digits are required after any prefix, and type modifier suffix
characters ('L', 'S', & 'U') are not accepted. Unlike C, Bash does not
recognize quoted characters as integer constants».
* OR add a "Proposed Future Changes" section to the top of CHANGES, with an
entry explaining this change and its rationale, AND delay actually
implementing the change until after the announcement makes its way into
common LTS channels (let's say, April of even-numbered years).
Now would be a good time to start working on a "proposed changes" section,
so that it will have plenty of time to be incorporated into the LTS
releases in April this year.
-Martin
PS: C is now quite peculiar in having "character constant" mean a kind of
*integer*, and aside from C++, probably no other common language shares
this feature. Even most C programmers do not fully understand what it
means, so VERY few Bash users would understand it without further
explanation. Even if you don't opt for my first preference, I suggest using
my replacement anyway, just without «no digits are required after any
prefix, and».
>
