On Mon, 18 Sep 2023 04:56:18 +0200 alex xmb ratchev <fxmb...@gmail.com> wrote:
> On Mon, Sep 18, 2023, 04:03 Kerin Millar <k...@plushkava.net> wrote: > > > Hi Victor, > > > > On Sun, 17 Sep 2023, at 8:59 PM, Victor Pasko wrote: > > > Hi, > > > > > > Could you please take a look at attached bug.bash. > > > > > > Maybe, not all math combinations were presented there or the test has > > > duplications somehow. > > > Here are results of several runs with test# as argument > > > > > > > > > *% bash --version*GNU bash, version 5.2.15(3)-release (x86_64-pc-cygwin) > > > > > > Good test without argument but others with errors :( > > > *% ./bug.bash* > > > > > > res1=010 good 010 base8 > > > res2=03 good 03 base8 > > > res=17 good result 17 base10 (res1+3*res2) > > > base10-res=19 good result 19 base10 (res1+3*res2) > > > base10-res=19 good result 19 base10 (res1+3*res2) > > > base10-res=19 good result 19 base10 (res1+3*res2) > > > res1=8 good result 8 base10 > > > res1=10 good result 10 > > > res1=10 good result 10 > > > res1=010 good result 010 base8 > > > base10-res1=10 good result 10 > > > res1=16 good result 16 > > > > > > > > > *% ./bug.bash 1* > > > TESTCASE=1 > > > res1=010 good 010 base8 > > > res2=03 good 03 base8 > > > res=17 good result 17 base10 (res1+3*res2) > > > base10-res=19 good result 19 base10 (res1+3*res2) > > > ./bug.bash: line 29: let: res = base10#010 + base10#03 * 3: syntax error: > > > invalid arithmetic operator (error token is "#010 + base10#03 * 3") > > > > This seems like a misinterpretation of the manual. The manual states that > > numbers "take the form [base#]n, where the optional base is a decimal > > number between 2 and 64 representing the arithmetic base". As such, > > "base10" is not a decimal number between 2 and 64, whereas "10" would be. > > > > > base10-res=19 good result 19 base10 (res1+3*res2) > > > base10-res=19 good result 19 base10 (res1+3*res2) > > > res1=8 good result 8 base10 > > > res1=10 good result 10 > > > res1=10 good result 10 > > > res1=010 good result 010 base8 > > > base10-res1=10 good result 10 > > > res1=16 good result 16 > > > > > > > > > *% ./bug.bash 2* > > > TESTCASE=2 > > > res1=010 good 010 base8 > > > res2=03 good 03 base8 > > > res=17 good result 17 base10 (res1+3*res2) > > > base10-res=19 good result 19 base10 (res1+3*res2) > > > base10-res=19 good result 19 base10 (res1+3*res2) > > > ./bug.bash: line 35: let: res = 10#res1: value too great for base (error > > > token is "10#res1") > > > > For numbers in the form "[base#]n", it isn't practically possible for n to > > be specified using a variable without prefixing it with a sigil (so that it > > is treated as a parameter expansion and injected). There is a very good > > reason for this: numbers in a base higher than 10 can require alphabetical > > letters to be expressed. Consider the following example. > > > > $ echo $(( 16#ff )) > > 255 > > > > some were prefixed with 0 which make those also not work You're probably thinking of the 'September' issue but it isn't true. Consider the declarations of res1 and res2. res1=010 # base8 number res2=03 # base8 number The comments make it clear that Victor is expecting for those to be treated as base 8 (octal). At least, without qualifying the base. There is no issue there; both are perfectly valid octal numbers. $ echo $(( 010 )) $(( 03 )) 8 3 On the other hand, the base number in "base#n" notation may not have leading zeroes. $ echo $(( 064#1 )) bash: 064#1: invalid number (error token is "064#1") However, that particular mistake is never made in the program. -- Kerin Millar
