Gilles's answer is (IMHO) brilliant (as always), but since you didn't choose it or even up-vote it, perhaps you find it too complicated. So here are a few (simple) points that might or might not be helpful, and may help you avoid maintaining two separate scripts, which could turn into madness for a large script that has to be maintained over a long period of time.
1) The AIX machines might have
bash installed even though it's not the default shell for interactive use. (The AIX machines I work with do have
bash installed, but I don't know if it came that way of the sysadmins added it. I'm guessing it came on it, since all our sysadmins are
ksh junkies.) And I'm willing to bet that the RHEL machines have
ksh installed. Check this, because if you can use the same shell on both machines it will save you a lot of hassle.
2) If you don't know where the shell is going to be installed, avoid putting its path directly in the shebang line. Instead put in the path to
env and the shell executable name afterward, like so:
This should work on both machines, but you'll have to test it to be sure. (The location for
env is supposedly more standard than the location for
bash or most other things.)
Once you're using the same shell on both machines, the problem might be solved right there. But if not...
3) You can break your platform-specific code out into functions that you source into the main script. This means that although script might have lots of places where things work differently depending on whether it's running on AIX or RHEL, you don't need to repeatedly check the platform. Just do it once, and source the appropriate functions:
case $OS in
echo "Exiting. The OS type is not found.";;
Now you can use whatever functions you sourced, all over your script without ever having to have another
case statement to distinguish between platforms:
do_something_platform_specific "$SOME_ARGUMENT" "$SOME_OTHER_ARGUMENT"