Wrappers

Directory Layout

Part of the key is understanding the directory layout. In the beginning you had a directory layout something like:

-----bin--foo.exe
  |       bar.exe
  |
  |--lib--libfoo.so

we're going to change that to:

-----bin-----foo.exe (a link to the wrapper)
  |       |  bar.exe (a link to the wrapper)
  |       |
  |       |--executables--foo.exe (the real binary)
  |                       bar.exe (the real binary)
  |
  |--lib--libfoo.so

which isn't such a big change. The user will still have .../bin on their PATH.

Wrapper Basics

When the user runs foo.exe they'll be running the wrapper. The wrapper is the same for all the commands so not only will it be working out what directory it is in but it will also have to determine the name of the command the user was trying to run.

Pretty much all of that can be worked out by looking at $0, the name the script was invoked as. People invoke commands in all sorts of funny ways:

• /full/path/to/bin/foo.exe - they typed the whole pathname in
• ./path/to/bin/foo.exe - they typed a relative pathname in
• ../path/to/bin/foo.exe - they typed a relative pathname in though this differs because we have to handle ..
• foo.exe - they simply typed the command name and the shell found it on their PATH.

but they're fairly easy to handle.

The wrappers goal is to recreate the full pathname to itself, /full/path/to/bin/foo.exe, after which we can work out the following:

BINDIR="${0%/*}"
EXENAME="${0##*/}"

which would be /full/path/to/bin and foo.exe respectively.

We can then calculate:

TOPDIR="${BINDIR%/*}"
LIBDIR="${TOPDIR}/lib"

and suddenly calculating LD_LIBRARY_PATH, CLASSPATH, PERL5LIB and TCLLIBPATH seem a whole lot easier.

Even easier still if we've included some simple functions to manipulate paths

Those functions will come in extremely handy if, for example, foo.exe invokes bar.exe and thus adds ${BINDIR}, say, to PATH repeatedly as we'd want to trim the path of repeated clutter.

Recreating the Full Path

Of the four ways we would normally expect to be invoked:

• /full/path/to/bin/foo.exe - we can leave alone
• ./path/to/bin/foo.exe and ../path/to/bin/foo.exe - we can mix with ${PWD}, the current working directory
• foo.exe - we'll have to find it on the PATH ourselves.

type -p $0

Running the Real Command

Finally, we need to run the real command. We know we stashed it in bin/executables so we should be able to execute it, passing it the arguments we were originally given:

exec "${BINDIR}"/executables/"${EXENAME}" ${1+"$@"}

Binaries

Your friend here is uname, in particular the mrps flags. uname returns the results in a consistent fashion so you might see results like:

SunOS 5.11 i86pc i386
Darwin 9.8.0 i386 i386
Linux 2.6.18-164.el5 x86_64 x86_64

and you can quickly produce a useful little function like:

_uname ()
{
    set -- $(uname -mrps)
    OS="$1"
    OS_REV="$2"
    case "${OS}" in
    SunOS)
       OS_ARCH="$4"
       ;;
    Darwin|Linux)
       OS_ARCH="$3"
       ;;
    esac
}

from which your executable directory would be:

${OS}-${OS_REV}-${OS_ARCH}

or

${OS}/${OS_REV}/${OS_ARCH}

or some other combination.

Scripts

That's good for binaries but what if I've written a script? Put it in a script subdirectory.

You could put it in a different subdirectory if you wanted to invoke a specific interpreter on the script. You have plenty of choice.

More Than One Place to Look?

With a possible binary directory (or directories) and a script directory to look in for your real command you have to make the wrapper a little more complicated as you try to see if the real command exists in any of the calculated subdirectories.

The order in which you search (primarily, do you look in the scripts directories before the binaries directories or vice versa) is a matter of personal taste. Of course, if you have both a script and a binary of the same name you might want to question what on earth you thought was going to happen.