n12:/home/vbe/wks/test/arithmetics $ bash
n12:/home/vbe/wks/test/arithmetics $ date +%j
010
n12:/home/vbe/wks/test/arithmetics $ let A=$(date +%j)
n12:/home/vbe/wks/test/arithmetics $ echo $A
8
n12:/home/vbe/wks/test/arithmetics $ A=$(date +%j)
n12:/home/vbe/wks/test/arithmetics $ echo $A
010
n12:/home/vbe/wks/test/arithmetics $ let B=$A
n12:/home/vbe/wks/test/arithmetics $ echo $B
8
Only workaround for now ( I have other things to do...) I can think of is:
n12:/home/vbe/wks/test/arithmetics $ echo "$A + $B" |bc
12
This is not a bug -- the leading 0 causes the shell to think the number is octal. 010 would be 8 in octal.
You can do string operations to strip off leading 0's, but I tend to take the easy way, slapping a '1' on the front to make it look decimal. Subtract 1000 as part of your math operations.
You could also user typeset to force the variable to be an integer:-
typeset -i Var1=$(date +%j)
I have noticed a difference in the output from this depending on the OS though.
It seems that AIX (4, 5 and 6) & HP-UX 11 do what I expect, but RHEL (bash & ksh93) computes this to set Var=11
Maybe it's to do with the version of the shell, but AIX 6 has ksh93 available and that works as I expect (value of 13). Something to be tested first. Maybe this would be safer:-
Perhaps I should have done a quick loop to test it out too. How embarrassing. :o
I suppose I could trim the possible first zero twice like this:-
typeset -Z3 testdate=1
while [ $testdate -le 370 ]
do
Var1="${testdate#0}" # Trim first zero only if it exists
Var1="${Var1#0}" # Trim off a second zero if that exists
echo $testdate $Var1
((testdate=$testdate+1))
done
Is that more expensive? It's a little easier to read than yours, but I'm prepared to be converted if there is a cost, especially as people may want to use this in a loop for all sorts of things.