Date: Tue, 19 Sep 2023 18:09:13 +0100
From: Kerin Millar <k...@plushkava.net>
Message-ID: <20230919180913.bd90c16b908ab7966888f...@plushkava.net>
| > | On Tue, 19 Sep 2023, at 8:40 AM, Victor Pasko wrote:
| > | > in let "<>" and $((<>)) constructs all variables should be
| > | > evaluated
| This assertion would be more compelling had you explained at some point
| during the ensuing treatise how to potentially square the request being
| made with the base#n notation, as presently implemented by bash.
I didn't even consider that case plausible, or what was intended, but now
I can see that maybe it was - but that could never work. Not (quite) for
the reason that you gave (or even Chet's explanation, though if he had
explained why it is like it is, the explanation might have been like I
am about to give), but because the syntax simply doesn't work out like that.
Given a token of x#y that's not a variable, variables have no #'s in their
names, so one cannot be expecting that (this would mean something entirely
different if actually written) ${x#y} to be evaluated in that case.
So, the only way to get variables out of that would be to split it into
two (or three) tokens, x and #y or x # and y. One might parse it like
that, and then evaluate x and y as variables, but if that were done, now
we'd have 3 tokens, not the one (representing a number in some other base)
to deal with, say 11 # 97 (where the 11 and 97 are now integers, not strings).
That's not what was desired, which was 11#97 as one token (106 decimal, if
my mental arithmetic is correct), and the only way to get it back would be
to invent a new (very high priority, must be higher than unary '-' for
example) # operator, which takes a base as its left operand, and a value
as its right, and somehow reinterprets the value in that base - but that's
essentially impossible, as we now have binary 97, which might have originally
been 0141 or 0x61 - 11#0141 is an entirely different thing from 11#97
and at this stage we simply wouldn't know which was intended.
So that method can't work either.
The $x#$y form works, as that (everything in $(( )) or other similar
contexts) is being treated just like inside a double quoted string.
Those get expanded first before being used, in this case as 11#97 (just
as strings, variable expansion has no idea of the context, nor does it
generally care what characters it produces) as a char sequence in the
effectively double quoted string. The arith parser can then parse that,
and see it has a specific base, and value - if y had been 0141 it would have
been parsing 11#0141 instead, unlike a simple reference of 'y' in the
expression, where all of 0x61 97 and 0141 turn into the binary value "97"
for arithmetic to operate on).
That's why I never even considered that might have been what was being
requested, it can't work as hoped.
kre
