Determine whether you think this directory requires additional subdivision. If so, be sure to use a consistent naming convention. The location of the wrapper determines the form of the command name links that must connect to it. For the purpose of this example, refer to the wrapper as being in the top level of this subdirectory and name it simply wrapper; in other words:

/usr/apps/pkgs/footool,v2.0/dist/wrapper

In many application packages, you must configure some of the files before the package can be run. If you are maintaining multiple application servers, consider the following:

•  Once you modify the original files, you may not have generic copies left. If you copy the package to another server, you may want the original files to match the vendor’s setup documentation.

•  If you synchronize the package between servers after setup, be careful not to overwrite the server-specific setups with those from another server.

Consider how you want to handle such files. One way is to identify the files that are candidates for modification and to make copies of them where they reside, using a suffix such as “.orig.” This convention preserves generic copies. You still must avoid shipping the modified versions of these files to other servers so that you do not overwrite local configurations that are already established.

Changes to the Default Package Version

Applications are installed into directories that identify their versions. Multiple versions can thus coexist at the same directory level. To identify the default version of a given application, create a generic directory name as a symbolic link pointing to the version-named directory that you want to serve as the default.

In the following example, the /usr/apps/pkgs directory contains two versions of FooTool and a generic footool name link:

$ cd /usr/apps/pkgs
$ ls -ld footool*
lrwxrwxrwx   1 nobody  nobody   12 Jun 19  1992/usr/apps/pkgs/
footool -> footool,v1.Ø
drwxr-xr-x  9 nobody  nobody  512 Jun 18 1992 /usr/apps/pkgs/
footool,v1.Ø
drwxr-xr-x  9 nobody  nobody  512 May  3 21:23 /usr/apps/pkgs/
footool,v2.Ø
$

The default version is footool,v1.0. If you want to change the default version to 2.0, remove the existing link and create a new link to version 2.0, as shown in the following example:

$ /usr/bin/rm footool
$ /usr/bin/ln -s footool,v2.Ø footool
$ ls -ld footool*
lrwxrwxrwx   1 nobody   nobody     12 Jul 19 Ø7:32 /usr/apps/
pkgs/footool -> footool,v2.Ø
drwxr-xr-x  9 nobody   nobody     512 Jun 18 1992 /usr/apps/
pkgs/footool,v1.Ø
drwxr-xr-x  9 nobody   nobody     512 May  3 21:23 /usr/apps/
pkgs/footool,v2.Ø
$

The version footool,v2.0 is the default for all users, because the symbolic links in /usr/apps/exe point to a wrapper using a path that refers to the directory named footool. This path now leads to the wrapper in footool,v2.0.

Developing Wrappers

The information in the following sections describe some basic information about how to develop wrappers. Refer to Part 6 of this book for an introduction to shell programming.

Interpreter Choice

You typically write wrapper scripts in an interpreted language so that they can execute on the various platform configurations in the environment. If you are going to write wrappers, you must decide which interpreter to use. Solaris 2.x provides three shells that make suitable interpreters for wrappers, as noted in Table 12-3.

SunSoft recommends that you use the Bourne shell to write wrappers. The Korn shell may not be available on some systems in the environment. Although the C shell is popular for interactive use, the Bourne shell is more advanced as a programming language. The C shell is also less portable because there are more feature variations between UNIX platforms. The Bourne shell supports functions—which result in code that is reusable in other wrappers—and the ability to pipe into and out of control constructs. The examples in this chapter use Bourne shell syntax.

---

NOTE:  In an environment that is so heterogeneous that even the Bourne shell is not universally available, you would have to seek yet another interpreter, possibly perl.

---

This is the first line in a Bourne shell wrapper script:

#!/bin/sh

Wrapper Directory and Naming

Create a subdirectory in the application directory, for example, /usr/apps/ pkgs/application-name/dist. Within that directory, create a wrapper that has the same name as the other wrappers. For example, name each wrapper “wrapper” (for example, /usr/apps/pkgs/application-name/dist/wrapper). When you use the same name for each application wrapper, it simplifies administration because you do not need to remember a host of different wrapper names. You can easily create links to any wrapper.

Command Name Evaluation

One of the first things a wrapper must do is evaluate the name that was used to invoke it. The wrapper has its own name. The wrapper name is different from any of the application command names, but the wrapper must know which command name it is being asked to represent.

For example, for package footool,v2.0, commands foo and bar each are links to the script called wrapper that is located in the /usr/apps/pkgs/footool,v2.0/dist directory. When a user types foo, the wrapper learns the name used to invoke it from the construct $0. In this case, $0 is /usr/apps/exe/foo. The /bin/basename command is used to strip the leading path, and foo is assigned to the variable cmd, as follows:

cmd=`/bin/basename $Ø`