I was "surprised" to find that /bin/sh and /bin/ksh have very different
arithmetic expression syntax.
ksh(1) says:
Integer constants may be specified with arbitrary bases
using the notation base#number, where base is a decimal
integer specifying the base, and number is a number in the
specified base.
However /bin/sh treats a leading zero as an indication the number is in
octal.
This lead me to the following in P1003-2001/SuSv3:
Next, the shell shall treat this as an arithmetic expression and
substitute the value of the expression. The arithmetic expression
shall be processed according to the rules given in "Arithmetic
Precision and Operations", with the following exceptions:
* Only signed long integer arithmetic is required.
* Only the decimal-constant, octal-constant, and
hexadecimal-constant constants specified in the ISO C standard,
Section 6.4.4.1 are required to be recognized as constants.
* The sizeof() operator and the prefix and postfix "++" and "--"
operators are not required.
* Selection, iteration, and jump statements are not supported.
As an extension, the shell may recognize arithmetic expressions
beyond those listed. The shell may use a signed integer type with a
rank larger than the rank of signed long. The shell may use a
real-floating type instead of signed long as long as it does not
affect the results in cases where there is no overflow. If the
expression is invalid, the expansion fails and the shell shall write
a message to standard error indicating the failure.
So I guess ksh is the odd man out here, though The KornShell book on
p.307 agrees with the pdksh implementation in how different bases should
be specified, so in terms of standardising existing practices the good
old POSIX boys failed miserably yet again.
So, I guess it's fair to have /bin/ksh follow the real Ksh, and for
/bin/sh to follow POSIX in this case, though sh(1) is sorely lacking on
any and all pertinent details about Arithmetic Expressions (we can't
expect everyone to have a copy of SuSv3 handy!).
On the other hand /bin/sh (at least on 1.6.2_STABLE) seems to have some
kind of parsing problem with recognizing operators when there are no
non-digit tokens surrounding them:
$ /bin/sh -c 'echo $((06170718+10000))'
arithmetic expression: syntax error: "06170718+10000"
$ /bin/ksh -c 'echo $((06170718+10000))'
6180718
However so long as there is a non-digit token before the operator it's
happy without any whitespace (just operating with different base
interpretations):
$ /bin/sh -c 'echo $(($(date +%m%d%H%M)+10000))'
1645163
# /bin/ksh -c 'echo $(($(date +%m%d%H%M)+10000))'
6181534
Is this a bug? (As far as I can tell SuSv3 is somewhat silent on the
lexical interpretation of arithmetic expressions.) Is this still a bug
in -current? Should I file a PR?
--
Greg A. Woods
+1 416 218-0098 VE3TCP RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com> Secrets of the Weird <woods@weird.com>