Shell Programming and Scripting

I first tried it on my NIM-Server, which happens to be also my script development system. Its version is basically 7.1 SP2. The first try is with the system shell (which is a ksh88), the second with the ksh93:

Code:

# lslpp -l bos.rte
  Fileset                      Level  State      Description         
  ----------------------------------------------------------------------------
Path: /usr/lib/objrepos
  bos.rte                   7.1.2.15  COMMITTED  Base Operating System Runtime

Path: /etc/objrepos
  bos.rte                   7.1.2.15  COMMITTED  Base Operating System Runtime
# instfix -i | grep ML
    All filesets for 7.1.0.0_AIX_ML were found.
    All filesets for 7100-00_AIX_ML were found.
    All filesets for 7100-01_AIX_ML were found.
    All filesets for 7100-02_AIX_ML were found.

# Version M-11/16/88f
# cont=1
# if [ cont -eq 1 ]
>then
>  echo "It works"
>fi
It works

# ksh93
# print - ${.sh.version}
Version M 93t+ 2009-05-01
# if [ cont -eq 1 ]
>then
>  echo "It works"
>fi
It works

To be honest, i'm dumbfounded. I would have never expected that to run. Btw., this only works with integers, not with strings:

Code:

foo="abc"
if [ foo == abc ] ; then
     print - "It works"
fi

will work as expected - which is: not work at all.

I got adventurous and tried to make the datatype more "stringy" and less "integerly":

Code:

typeset -RZ3 foo=1
# typeset -RZ3 foo="01"

print - $foo
if [ foo -eq 1 ] ; then
     print - "It works"
fi

both of which works too - "foo" gets expanded.

The next thing i wondered was: is this specific to the AIX-ksh? In fact it is not. My colleague from the Linux-team tried it on a couple of our SLES11-servers and the ksh93 there worked the same. As it seems this is no specific feature of the AIX-shell but a common treat of the Korn shell.

I hope this helps.

bakunin

Thanks! wow so it's a korn shell issue and it behaves the same way in Linux. That's another important step..

We were completly shocked as well.

I'd like to share the story. This is what happened:

- First we found out that a lot scripts were "wrong", which is very strange because is a bank..
- We asked the bank, because we are outsourced, about this issue, and they said: you are right, those scripts are wrong. (lol)
- Then we decided we had to fix that so those scripts work properly in RHEL now. But.. wait! if there are a lot of scripts that didn't work for years, if you now make them work.. what will it happen???
So we agreed to fix it only and just only we had the approval of all the people in charge.
The next day we got an email saying: No, don't "fix" anything at the moment and just take notes of when you found something is wrong.
- As we kept going we saw more and more scripts.. hundreds.. so what's going on??
- Then someone saw the light and realised that those scripts actually work. I was so shocked and puzzled I said to my manager: alright! I'm leaving! lol
- So I don't know what kind of mess they have they don't even know about which script is working, etc........
- The thing is that now we haven't got any more time to do those changes manually so we had to think about how to do a massive change tool to change all scripts and make them have the preceding "$" in each case, whithout messing them all up, and messing all the work we had done already. This was a problem, because it seemed kind of easy, just a matter of finding the right regular expression.. but we found out that it didn't work properly and not only worked.. but it messed up some scripts.. so we ended up using a higher level language and, instead of using regular expressions, something far less elegant but more effective: searching for the lines where there were a variable wihtout a "$", filtering it into the unique lines, and then modifiy it manually and make a file with the origin and the target, separated with "@@@" (as an example). We used a higher level language to make the substitution in all scripts and it worked perfectly except for 200 scripts, with just scripts that didn't work.
We have been working monday to sunday lately..

So now I believe in God again lol!

Yes, even these seem to work:

Code:

foo=8#14
[ foo -eq 12 ] && print - "It works"

foo=21+3-0x0A
[ foo -eq 14 ] && print - "It works"

Addendum: i got me a Ubuntu system and the code works there too. This seems to be a ksh issue rather than an AIX issue:

Code:

# echo ${.sh.version}
Version JM 93t+ 2010-03-05
# foo=1
# if [ foo -eq 1 ] ; then echo "works" ; fi
works

Systems tested to behave in the described manner so far:

AIX
SLES 11
Ubuntu 10.04 LTS

bakunin

Also Solaris 10:

Code:

$ uname -rs
SunOS 5.10
$ foo=1
$ if [ foo -eq 1 ] ; then echo "works" ; fi
works

I was asked to take a look at this and comment on what the standards say about this ksh behavior. The standards leave unspecified what happens if both operands of the test -eq, -ne, -lt, -le, -gt, and -ge binary primaries are not integer operands.

The standards allow, but do not require the test expression and [ expression ] utilities to be implemented as shell built-ins (as they are in bash and ksh)). If test and [ ... ] aren't implemented as shell built-ins, there is no way that the behavior shown here would be possible. In ksh (at least ksh on AIX and on OS X), if a variable name is given where a number is needed in these cases, the value of the variable is substituted into the expression even when the $ is not present.

The standards specify this behavior for arithmetic expansions. That is, the sequences:

Code:

n=0
while [ $n -lt 5 ]
do      printf "%d\n" $(($n++))
done

and:

Code:

n=0
while [ $n -lt 5 ]
do      printf "%d\n" $((n++))
done

are required to do the same thing. So, it seems like a logical extension to me to not require the $ in the expression in these test exp ([ exp ]) expressions either.

Obviously, this need not be portable to other shells and might not even be portable to other versions of ksh.

Another thing.

If testing something like this (contents of test.sh)
(This code is not inside a loop.)

Code:

var3=1
case $var3 in
  1) var1=1
     break ;;
  2) var1=1
     var2=2
     break ;;
  *) echo "Error" ;;
esac

The thing is that when executing this code with ksh (RHEL 6.5) there's no error message from the shell.

But when executing with bash there's an error message when case has to evaluate a condition with break. When executed with ksh or sh, there's no error message.

Code:

[root@xxxx]# bash test.sh
test.sh: line 5: break: only meaningful in a `for', `while', or `until' loop
[root@xxxx]# ksh test.sh
[root@xxxx]# sh test.sh

As far as I know, break it has sense only when there's a loop. But since there's no error message for ksh and sh it looks like the behaviour for case is different from bash.

case syntax without break works fine in ksh and sh, with no error messages. Same with bash, as expected.

Any thoughts about this behaviour?

This is probably the same behaviour in ksh-AIX but I couldn't access a machine to test it right now.