Date: Tue, 19 Sep 2023 09:52:21 +0100 From: "Kerin Millar" <k...@plushkava.net> Message-ID: <4c2e3d39-0392-41ae-b73c-3e17296a9...@app.fastmail.com>
| On Tue, 19 Sep 2023, at 8:40 AM, Victor Pasko wrote: | > Thanks for your response. | > In my opinion, in let "<>" and $((<>)) constructs all variables should be | > evaluated, so that $-sign for them is to be just optional | | You haven't thought this through. You didn't think that through. | It would amount to an egregious break of backward compatibility, That's correct, but | How would you expect for digits above 9 to be expressed for bases above 10? that's completely missing the point Victor was making. But Victor, they are all evaluated (in many shells, just once), if you have a=10 then $(( a + 5 )) and $(( $a + 5 )) achieve exactly the same thing. To be postable however if we also have b=a then $(( b + 5 )) is quite likely to fail, whereas $(( $b + 5 )) will work fine (after expansions it becomes $(( a + 5 )) which is evaluated as above. However, where the expansions are really needed is with o1=+ o2=* used in $(( 10 $o1 5 $o2 6 )) If we were to write it instead as $(( 10 o1 5 o2 6 )) then the expression parser would have no idea at all how to interpret that, as var names are not evaluated until needed in the expression - what's there is just meaningless nonsense. But when the variables have the $ ahead of them, the expression parser sees $(( 10 + 5 * 6 )) and can build the correct evaluation tree to generate 40 as the answer. (The "10" could have been any of 'a' '$a' or '$b' given the values assigned earlier, that would make no difference, the ' chars there are just for clarity in this e-mail, not to be included). Much more complex expressions, which rely upon vars being expanded before the expression is parsed, can also be created, but not really needed here. kre