On Tue, Sep 19, 2023, 21:14 Kerin Millar <k...@plushkava.net> wrote:
> On Wed, 20 Sep 2023 01:41:30 +0700
> Robert Elz <k...@munnari.oz.au> wrote:
>
> > 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.
>
> It is exactly the nature of the request. I don't know whether you looked
> at Victor's "bug.bash" script. To recap, it contains a number of arithmetic
> expressions, beginning with "res = res1 + res2 * 3" (clearly understanding
> it to be fine). Ultimately, the script solicited a response concerning two
> particular situations. Firstly, this.
>
> let "res = base10#$res1 + base10#$res2 * 3"
>
me to get into the mails topic ..
.. what are res1 and res2 values
Rightly dismissed as invalid syntax so there is nothing more to be said for
> that.
>
> Secondly, this.
>
> # without $-signs before both res
> let "res = 10#res1 + 3 * 10#res2" # let: res = 10#res1: value too great
> for base (error token is "10#res1")
>
> I explained in my initial post that the sigils are required because "res1"
> and "res2" will otherwise be treated as integer values that (in this case)
> happen not to be within the scope of the specified base. Victor did not
> respond to this post but responded to a subsequent post by Chet, opining
> that $ should be "optional" regardless. That is the point at which I
> concluded that the matter had not been thought through.
>
> Anyway, thank you for the additional commentary.
>
> --
> Kerin Millar
>
>
