On Tue, Sep 19, 2023, 22:08 alex xmb ratchev <fxmb...@gmail.com> wrote:
> > > On Tue, Sep 19, 2023, 21:54 Kerin Millar <k...@plushkava.net> wrote: > >> On Tue, 19 Sep 2023 21:29:32 +0200 >> alex xmb ratchev <fxmb...@gmail.com> wrote: >> >> > 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 >> >> It really doesn't matter (see below). >> >> > >> > 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") >> > > so u mean a $ sign requirement ? > i didnt get the base values , i tried simple one > i faced the ' without $ it doesnt work ' > > This is what matters. The implied complaint is that the $ symbols have to >> be there and that they should somehow be optional. In other words, Victor >> wants for "res = 10#res1 + 10#res2" to be able to consider res1 and res2 > > > optional as in make default values in if empty ? > > ~ $ b1=29 b2=39 a1=29 a2=29 c1=$[ b1 ? b1 : 10 ] c2=$[ b2 ? b2 : 10 ] t1=" > $a1#$c1 * $a2#$c1 " r1=$[ t ] ; echo $r1 > 4489 > can i lightly suggest once more bash to use bignum libs as (variable) identifiers instead of integer constants. Both "res1" and >> "res2" are perfectly valid integer constants for bases between 29 and 64. >> >> $ echo $(( 29#res1 )) $(( 29#res2 )) >> 671090 671091 >> >> That is why bash correctly complains that the value is too great for the >> base of 10. It doesn't matter whether res1 or res2 exist as variables, >> whether they are set or what their values are. The n in base#n notation is >> always taken as a number, so the only way to have n be the value of a >> variable is to expand it. >> >> -- >> Kerin Millar >> >