Need help with script and shell math (HPUX 11)

[Pat Watson]

We have a cron-run script that calculates the current date in Unidata internal format and puts it in a variable. Here is the problem that I need help with:

If the script does not specify "/usr/bin/ksh" as the first line (thus defaulting to the "sh" shell), it calculates something but the date is incorrect during julian dates through 099 because the sh shell thinks the julian date represents an octal number. Once we hit 100 and there is no leading zero, all is well.

If I do specify the "ksh" shell, the script does not appear to hold on to the variable (or maybe nothing is calculated to begin with). The script works fine (meaning the variable is populated) if it is run in *interactive mode*, but when it runs under *cron* there is nothing passed to the paragraph.

Here is an example of what I am trying to do:
S2007=14246 day of the year in internal format>
.
.
# Generate current date in internal format
# (We take the current year and prepend an
# "S" to get the first day of the year
# from the above table. Then we add the
# current Julian date to the first
# day of the year (minus 1 since Jan 1 is
# day 1 on the Julian calenar.)
idate=$((S$(date +%Y) + $(date +%j) -1))

Can anybody help me with this?

[Srini Jay · Accepted solution]

Try this to avoid leading zero:

date +%-3j

instead of date +%j

[Peter Nikitka]

Hi,

- I would really declare your variable(s) Snnnn as integer:
typeset -i S2007=14246
date=$((S$(date +%Y) + $(date +%j) -1))
Else there may be an additional 'eval' necessary.

- Make shure, your locale settings do not interfere; put something like that at the beginning of your scr ipt:
export LC_TIME=C LC_NUMERIC=C

mfG Peter

[Bob E Campbell]

I spent a lot of time last week dealing with a standards related issue, so just for fun I checked to see if this was another area where standards make a difference:

# unset UNIX95
# S2007=14246
# echo $((S$(date +%Y) + $(date +%j) -1))
14289
# export UNIX95=1
# echo $((S$(date +%Y) + $(date +%j) -1))
14281

Yup, chalk up another one!

[Pat Watson]

Thank you, the problem appears to be solved.

Now I just need to figure out what the "-3" does...but that is purely research.

[James R. Ferguson]

Hi Pat:

In fact, to add to Bob's comments, the 'sh-posix' manpages document the UNIX95 behavior (see the section on arithmetic evaluation):

/*begin_quote*/

Arithmetic expressions given with let command, ((...)), and $((...)) will be processed according to ISOC standard with the exception of ++, --, ?:, and , operators. Integer constants beginning with 0 and 0x (or 0X) will be recognised as octal and hexadecimal numbers by these evaluators only if environment variable UNIX95 is defined.

/*end_quote*/

Regards!

...JRF...

[Pat Watson]

Interesting.

Any idea why adding the shell declaration at the top of the script to force "ksh" would cause the idate variable to be empty?

[Bill Hassell]

First, it's absolutely imperative that ALL your shell scripts start with #!/usr/bin/someshell. The main reason is that your script will be processed by the current shell which might be sh-posix, bash, csh, whatever. There are other reasons that have to do with the environment setup -- they are obscure but can cause these types of problems.

The leading 0 = octal problem has been around for a long time. Back in the days of minicomputers with 8bit processors, almost everyone used octal notation, even dividing a 16bit front panel display into 5 groups of 3bit 'tribles' plus a single bit. So a leading zero became the defacto standard to flag octal numbers.

Unfortunately, it was not 100% implemented and octal numbers are extremely difficult to decode 8bit characters. Thus, hex numbers became much more commonplace and there is no mistaking the hex flag 0x.

All that said, the sh-posix patch PHCO_25597 (11.11) and PHCO_26789 (11.00) fixes the long-standing error in following the ISOC standard for octal number interpretation. Indeed, when the patches were released, it exposed errors in old rc start scripts that used leading zeros. Luckily, the scripts referred to 08 and 09 (both illegal octal numbers) and the scripts flagged themselves in /etc/rc.log.

This is one of the strong reasons to use typeset for numeric variables and computation, then format the result with typeset -Z when necessary.

[Heironimus]

You should also be able to use the "base#" notation to force it to use decimal (base-10), but I haven't tried that on HP's POSIX sh. It'll only apply when the shell knows it's a number, so you need to be either inside an arithmetic expression or assigning to a variable you've declared with "typeset -i".

$ echo $((5 + 010))
13
$ echo $((5 + 10#010))
15