Previous Table of Contents Next


Environment Variables

Many applications require that you assign environment variables before you can execute them. Environment variables usually are values that cannot be reliably predicted by the compiled code, such as the directory where the application is installed. Such variables must be set and exported to be available to subsequently executing processes, just as they would be from a user’s dot files. In Bourne shell format, the syntax is as follows:

export FOOHOME
FOOHOME=/usr/apps/pkgs/footool,v2.0


NOTE:  You can export the environment variable either before or after you assign it a value.

Platform Evaluation

Not all applications support all combinations of hardware platforms and operating systems that may be in your environment. Therefore, you need to evaluate the user’s platform to see if service can be provided.

For example, if footool,v2.0 supports only the Sun4 platform, the code shown here declines service (politely) to all other platforms:

case $arch in
      sun4)
           ;;
      *)
           echo >&2 “Sorry, $cmd not available for $arch architecture.”
           exit 1
           ;;
esac

Command Path Construction

Next, you define the variable command in terms of code that will yield the complete execution path to the application binary.


NOTE:  The wrapper may not, in fact, execute the binary itself, but rather, may invoke a link that the vendor has routed through its own wrapper, as is the case with the product FrameMaker.

In the footool,v2.0 wrapper, you might write a command path definition, as shown here:

command=$FOOHOME/bin.$arch/$cmd

The command path definition could be more complex, or it could be as simple as that shown here:

command=$FOOHOME/bin/$cmd

Exec/Argument Passing

The wrapper has now made its assignments and calculations and has determined that the service is available for this user. It is time to hand off execution to the application and get out of the way, via the exec statement. The wrapper process has navigated to the correct binary and passed on the necessary environment. It then vanishes and imposes no further burden.

The last action of the wrapper is to make sure that any arguments the user included on the original command line get through exactly as expressed, which is the purpose of the ${1+“$@”} construct at the end of the exec statement shown below:

exec $command ${1+“$@”}

A Basic Wrapper

At this point, the wrapper looks like this:

#!/bin/sh
    cmd=`/bin/basename $Ø`
    export FOOHOME
    FOOHOME=/usr/apps/pkgs/footool,v2.Ø
    case $arch in
       sun4)
           ;;
       *)
           echo >&2 “Sorry, $cmd not available for $arch architecture.”
           exit 1
           ;;
    esac
    command=$FOOHOME/bin/$cmd
    exec $command ${1+“$@”}

The wrapper example is not quite complete; it does not consider how $arch gets defined. The code necessary to assess architecture varies depending on the mix of platforms in the environment. However, in a given environment, you would need to use this same code for many wrappers. You can create the code as a Bourne shell function that can be replicated in as many wrappers as necessary.

In fact, for ease of maintenance, you might choose to make this code one function among others in a library external to the wrappers themselves. The wrappers requiring this function then merely source it from the library and execute it at the appropriate point in the wrapper. In this way, you often can carry out maintenance required by the wrappers by updating the library that supports all the wrappers. See Chapter 17 for some examples of wrapper functions.

If you provide a function library, be sure to use a consistent naming convention so that the wrappers can access and source the wrapper functions. You may want to apply the version-naming convention to this directory as well. For example, you might create a directory named /usr/apps/library,v1.0.

When a function library exists, you use the functions in scripts by defining the library location and sourcing the function script at the beginning of the wrapper. Then, before you use the $arch variable, you set it, as defined in the wrapper function. Next, you would execute the function at the appropriate point in the wrapper to return the values required. Remember, our wrapper example here is intentionally basic. The bold lines in the following example show the additions made to the basic script. See Chapter 17 for an example of the function arch.sh.fctn.

#!/bin/sh
library=/usr/apps/pkgs/library,v1.Ø
. $library/sh/arch.sh.fctn
cmd=`/bin/basename $Ø`
export FOOHOME
FOOHOME=/usr/apps/pkgs/footool,v2.Ø
arch=`Arch`
case $arch in
   sun4)
     ;;
   *)
     echo >&2 “Sorry, $cmd not available for $arch architecture.”
     exit 1
     ;;
esac
command=$FOOHOME/bin/$cmd
exec $command ${1+“$@”}


Previous Table of Contents Next