1

I have a ksh93 script that I'm migrating from AIX 6.1 to AIX 7.1

It's failing on 7.1 but works fine on 6.1. Here's a snippet of the important parts.

integer f_count=0
   . . . 
   . . . 
   . . . 
if [[ ($f_count*$sleep_interval%$alarm_interval -eq 0 ) && $f_count > 0 ]]       
then

When it hits the "if" I get

line 191: *10%300: arithmetic syntax error

I decided to simplify it by typing this at the command prompt.

AIX 7.1> integer x=1          
AIX 7.1> [[ $x*10%300 -eq 0 ]]
AIX 7.1> print $?
1
AIX 7.1> integer x=0          
AIX 7.1> [[ $x*10%300 -eq 0 ]]
-ksh93: *10%300: arithmetic syntax error


AIX 6.1> integer x=1          
AIX 6.1> [[ $x*10%300 -eq 0 ]] 
AIX 6.1>  print $?                                                                                        
1
AIX 6.1>  integer x=0                                                           
AIX 6.1>  [[ $x*10%300 -eq 0 ]] 
AIX 6.1>  print $?                                                                                        
0

To show it's ksh93 on AIX 6.1 I did this.

asdlkfjasd
-ksh93: asdlkfjasd: not found.

If I move the 0 value so it's not first, it works as expected.

AIX 7.1> integer x=1            
AIX 7.1> [[ 10*$x%300 -eq 0 ]]  
AIX 7.1> print $?             
1
AIX 7.1> integer x=0           
AIX 7.1> [[ 10*$x%300 -eq 0 ]]  
AIX 7.1> print $?             
0

This will fix my issue as I know the 2nd and 3rd variables in my original equation will never be 0.

Is this showing an AIX 7.1 bug?

2
  • Whats the content of ${.sh.version} on both systems? Nov 9, 2016 at 15:39
  • (on mine: AIX6 = Version M-12/28/93e; provided by bos.rte.shell 6.1.9.45, AIX7 = Version M 93t+ 2009-05-01; provided by bos.rte.shell 7.1.3.45)
    – Jeff Schaller
    Nov 9, 2016 at 15:53

3 Answers 3

1

Looks like you've found a bug in ksh93.

I can reproduce it (ksh93u+) with:

$ x= ksh -c '[[ 0*1 -eq 5 ]]'
ksh: *1: arithmetic syntax error

It's OK with:

ksh -c '[[ " 0*1" -eq 5 ]]'

though. And it seems it was fixed in ksh93v- (beta) as I can't reproduce it there.

Anyway, I would use:

if ((f_count * sleep_interval % alarm_interval == 0 && f_count > 0)); then

A few notes:

  • inside [[...]], > is for string comparison (where 10 is less than 2 and depending on the locale, -1 may be greater than 0). Use -gt for numerical comparison (though it's better to use ((...))).
  • avoid expanding variables inside arithmetic expressions, as in, use x instead of $x. For instance, compare:

    $ x=-1 ksh -c '((-$x > 0))'
    ksh: --1 > 0: assignment requires lvalue
    

    with

    $ x=-1 ksh -c '((-x > 0))'
    $
    

    Or:

    $ x=1+1 ksh -c 'echo "$(($x * 2)) $((x * 2))"'
    3 4
    
3
  • Thanks for the reply. So, who do I report a bug like this to? Is it an IBM implementation of ksh93 issue, or is there group that maintains ksh and IBM just gets a copy from them? Thanks again.
    – Scavenger
    Nov 9, 2016 at 15:40
  • Thanks also for explaining what the [[ ]] are for. I've never seen a good explanation of when to use them, or what the difference is from (( )).
    – Scavenger
    Nov 9, 2016 at 15:46
  • 1
    @Scavenger, the future of ksh93 is currently uncertain. Several bugs have been reported at github.com/att/ast/issues, but no work on them. Anyway, it looks like your issue has already been fixed. You could still report the bug to your Unix vendor so that they backport the fix or eventually move to a newer version when they have received enough reports like that. Nov 9, 2016 at 15:55
0

It does appear that ksh's doing something different with the arithmetic expansion; to work around it, I would explicitly use arithmetic substitution, which behaves as expected on both AIX 6 & AIX 7:

...
if [[ ( $((f_count * sleep_interval % alarm_interval)) -eq 0 ) && $f_count -gt 0 ]] 
...
0

Maybe answer is straight forward; you see problem when a variable at start of an arithmetic expression expands to 0 (zero). This is for left operand of -eq in KSH conditional expression - with -eq being numeric comparison, the operator expects a number as its left hand operand.

When expanding/evaluating the operands operator needs to do three steps: a) expand variables, b) strip leading zeroes, c) evaluate expression; in this order, then you will get the observed problem.

If the older Shell versions did it in this order: a) expand variables, b) evaluare expression, c) strip leading zeroes; then you will not see the problem

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .