script bug?

[Robert Grabowy]

we have two identical servers running same os and patch level. On wednesday evening we installed qpk and hwe 9/02 bundles. The next day several scripts were failing that contained the following while statement:

STARTHOUR=6
ENDHOUR=15
hour=08
while (( $hour >= $STARTHOUR && $hour < $ENDHOUR ))
do
echo "running while number 1"
done

The weird part is that it fails when hour = 08 or 09. 01-07 or 10+ works fine. I don't like blaming patches for script errors but it's an awful coincidence.

[A. Clay Stephenson · Accepted solution]

Make this change and all will be well,

hour=08
to
typeset -i hour=08

The shell is trying to intepret 08 as octal and ,of course, 08 & 09 are invalid octal values.

The typeset coerces the intepretation as decimal integers.

[Robert Grabowy]

Thank you very much. That worked. Won't I don't understand is why it worked prior to the upgrade. The other server in the pair has not completed the upgrade yet and the script works fine. Thanks again.

[A. Clay Stephenson]

While I don't specifically know caused your problem, I'm betting that it's related to shared library routines.

The strtol (string to long) function, if given a zero base argument, works like this:
If it sees a leading '0' then the value is interpreted as octal, if it sees a leading 0x or 0X, the value is intepreted as hexadecimal. Otherwise the value is decimal.

Man strtol for details.

I've seen this 'problem' occur between diffrent platforms and flavors of UNIX and when patches are appiled. The disciplined shell programmer will assume this behavior if any variables might have leading zeroes and typeset the variables to avoid this. This is one of those cases when you understand the underlying C, it's easier to understand what's going on.

Regards, Clay

[Robert Grabowy]

HP helped me find the culprit:
PHCO_26789
You were correct though. From the script text:
The shell now recognizes octal and hexadecimal numbers inside arithmetic expressions. This may impact the behavior of certain scripts.