On Sun, 10 Dec 2023, 12:15 Zachary Santer, <zsan...@gmail.com> wrote:
> On Thu, Nov 30, 2023 at 5:19 AM Martin D Kealey <mar...@kurahaupo.gen.nz>
> wrote:
> > > > This change will break scripts that use $((10#$somevar)) to cope with
> > > > somevar having leading zeroes OR BEING EMPTY.
> Beside the point, but I wanted to point out how easy this is to work
> around.
>
WRITING a work-around is trivial. I did that a long time ago.
DEPLOYING a work-around is a much bigger deal. I have no way of contacting
most of my users, and they weren't installing packages that I could push
updates to. I'm still getting sporadic complaints from users I've never
heard of, as they finally upgrade to newer versions of Bash and my old
scripts fail as a result.
To say that I'm peeved by the unnecessary work this has created for me
would be an understatement.
Quick hack changes like this need to be considered carefully, not rushed
through in a few days.
And sometimes Bash isn't the thing that needs fixing. Maybe the manual
needs to be clearer that "#" is not an "operator" like "+" or "/" but
rather part of an unsigned integer constant (and that "-" is NOT part of
such a constant).
But even if you still thought this was worth doing, it wasn't necessary to
make $((10#)) completely illegal: Bash could look ahead and only intervene
if the following character is '-' (affecting $((10#-digits)) but not
$((10#))).
Moreover, it only needed to output a warning, rather than fail, perhaps
“Warning: base# may only be followed by digits; "-" interpreted as
subtraction rather negation.”
If I were fixing this today, I would introduce a new category of
diagnostics that are only displayed when set -x is in effect (and sent to
>&${BASH_XTRACEFD-2}). Then I'd raise such a warning about 10#- but with
the old zero value.
-Martin
>
