Shell Programming and Scripting

What would be the best way or method to determine or test for the shell interpreter at the beginning of a script in the event one shell is not available?

If I use the following:
#!/bin/bash

and /bin/bash is not available, then use I'd like to use /bin/ksh if it is available.

#!/bin/ksh

One thing I have done over the years is create a standard set of libraries that I source near the top of my scripts with something like this:

Code:

[ -f ${LIBDIR}/bashlib.sh ] && . ${LIBDIR}/bashlib.sh

Within that library file I have something like this:

Code:

if [ -z "${BASH}" ]
then
    $printf "${SCRIPT}:${LINENO}: please run this script with the BASH shell\n" >&2
    exit $EXIT_VAL
elif [ ${BASH_VERSINFO} -lt 3 ]
then
    printf "${SCRIPT}:${LINENO}: BASH version 3 or greater is required\n" >&2
    exit $EXIT_VAL
fi

Unfortunately, I don't know of a way to dynamically change the "shebang" line since it is the first line of the script. You could potentially use a wrapper that uses a shell that you know is always available which then calls your other scripts using the preferred and available shell.

I understand not having the same shells available when you have multiple platforms (i.e. Solaris, HP-UX, Linux, etc.), but I would be concerned if you have systems that are the same platform and version but with different installation standards. This is especially true in a large data-center. Also, if you know that systems will not all have the same shells, I would recommend using the least common denominator. So if the all have sh or csh, I would write my scripts using one of those.

Just my .02.

-B

I agree with "bwhited".
If possible, write the script to the lowest common denominator.

Failing that write a controlling script in basic shell which calls named scripts containing a shebang for the preferred shell.

I usually use "uname -s" to identify the environment, but a truly portable script will need to know versions.

IMHO variations on "echo", "find", "awk" (or "nawk"), and "df" (or "bdf") are the biggest pain. You either need a portable script which decides which command suits the environment or a suite of custom scripts for each environment.

BTW. If all your systems are modern this board will seek out the POSIX shell. No problem there.

Others may wish to comment.

If it's sketchy at all, stick with /bin/sh.

Current /bin/sh (POSIX) is quite different from say Berkeley /bin/sh (BSD).
That is the issue.

I think most systems used now have POSIX built in commands, correct?

Interesting point, that Classic Shell Scripting book suggests using printf instead of echo due to this, but I've not really seen this in practice.

I learned heavy way about 1991, don't use system *sh paths or do any rename or ...
In one unix sh was special sh and there was also sh5. I copied sh5 to sh and after that "no boot ...".

After that I have done every system where I execute any scripts:
cp somecorrect_sh /usr/local/bin/mysh
And after that I have used mysh in my script
#!/usr/local/bin/mysh

It's so different to use ksh89, ksh93, posix-sh, original Bourne Shell, bash, ... so often /bin/sh is some of those. It depent which *nix and which release you are using. /bin/sh is some sh ...

Example, if you like to use always ksh93, then download it
software download selections

Same situation/method with bash + awk. Today I know which version I'm using. I have done own copies.


If you like to test, try substr
a="123"
print ${a:1:1}
# result must be 2, if you have posix-sh/ksh93 compatible shell
# if result is something else, then you have old sh: ksh89, old posix-sh or bourne shell
# if you have bash, print give error, bash can use echo and printf, but not print,
# maybe bash 4 include print, I have not tested