Korn Shell String Comparison problem

[irt_1]

This is the os version:

mddv02@/apps/bin>getconf KERNEL_BITS

64

The following script give the expected result:

#!/usr/bin/ksh

this_file_date=12345678901234

last_file_date=02345678901234

if [ $this_file_date -gt $last_file_date ]; then

# echo $raw_file_name >> $FTP_LIST

echo "select:" $this_file_date

fi

mddv02@/apps/bin>ksh test2_string.ksh

select: 12345678901234

The Next one doesn't give us the correct result

mddv02@/apps/bin>cat test2_string_no.ksh

#!/usr/bin/ksh

this_file_date=123456789012345

last_file_date=023456789012345

if [ $this_file_date -gt $last_file_date ]; then

# echo $raw_file_name >> $FTP_LIST

echo "select:" $this_file_date

fi

mddv02@/apps/mdsamd/mdsamd/arc/bin>ksh test2_string_no.ksh

mddv02@/apps/mdsamd/mdsamd/arc/bin>



So the problem if the value of the string is more than 14 characters it can not compare correctly (the second script is the one with more than 14 characters). Is it a bug? if it's a bug, any fix? Or is this the limitation of the HPUX?

(BTW those 2 scripts can run in Tru64 Unix without problem)

Thank You,

[Mark Grant]

These have to fit in a "long integer" which makes these two variables -2045911175 and
1972608889 respectively. My guess is that True64 has a longer long.

[Mark Grant]

By the way,

You can get around the problem like this

#!/usr/bin/ksh

this_file_date=123456789012345

last_file_date=023456789012345

(( result = $this_file_date - $last_file_date ))

if [ $result -gt 0 ]; then

# echo $raw_file_name >> $FTP_LIST

echo "select:" $this_file_date

fi

[Jdamian]

Hi.

I suggest to use 'bc' command to handle large integers:

echo "if ($this_file_date>$last_file_date) a=a+1; a" | bc | read OUTCOME
if [[ "$OUTCOME" -eq 1 ]]
then
.
.
.
fi

[Graham Cameron_1]

As suggested you need to take care with long integer arithmetic, the shell doesn't handle too well, bc is better.

One of the suggestions above may not give the results you expect. ie.

# this_file_date=123456789012345
# last_file_date=023456789012345
# (( result = $this_file_date - $last_file_date ))
# echo $result
276447232

whereas if you use bc:
# bc

123456789012345-023456789012345
100000000000000

There have been previous neat solutions where bc is used as a co-process from a shell.

Something like

# bc |&
# print -p $this_file_date -$last_file_date
# read -p answer
# if [ $answer -gt 0 ] ;then etc...;fi
# print -p quit

-- Graham

[Mark Grant]

Graham,

I realised whilst out having a quick smoke that the workaround I posted earlier is really not a good idea and if it works, it works for the wrong reasons.

I'd do it in perl :)

[irt_1]

Hi Guys,

Thanks alot for the very quick answer. I think the problem is more like what Mark Grant said. is about the diff. between how long the integer value in HPUX and Tru64.

Then another question pop up. Anyone know how long the integer in HP/UX Korn Shell? Can we use longer integer value?

The problem I can not just change the script, is by the Application Vendor. But if it's the way HPUX integer should be, I can ask the Apps Vendor to change, as long as it is not a bug.

Thank again,

Iwan

[Graham Cameron_1]

Does TRU64 have getconf command?

Here's what I get on my hp-ux system.

getconf INT_MAX
2147483647
getconf KERNEL_BITS
64

-- Graham

[Mark Grant]

Have a look at /usr/include/sys/_inttypes.h for a definitive list.

I suspect you need to start talking to your vendor!

[Armin Kunaschik]

Looks like your numbers are out of range.
This is not a HP-UX problem, but a ksh problem.
Try to compare the strings instead:
if [[ $string1 > $string2 ]]
then
do_something
fi