Using a Common Command Directory

You should create symbolic links for all application command names in the /usr/apps/exe directory. When you do so, users can access all of the software in the distribution with a single, unchanging path component.

If you choose to have a common command directory for a parallel hierarchy, as mentioned previously, two path components are sufficient to access the entire distribution.

The command names are symbolic links that point to the location of the wrapper for their application. Many applications, such as MatLab and FrameMaker, come with separate subprograms, and you need to create symbolic links to the wrapper for each subprogram For example, if the package FooTool 2.0 has the commands foo and bar, create these names as symbolic links in /usr/apps/exe, as follows.

$ cd /usr/apps/exe
$ /usr/bin/ln -s /usr/apps/pkgs/footool/dist/wrapper foo
$ /usr/bin/ln -s /usr/apps/pkgs/footool/dist/wrapper bar
$ ls -l foo bar
lrwxrwxrwx   1 nobody   nobody        35 Apr  6  1992 foo -> 
 /usr/apps/pkgs/footool/dist/wrapper
                                           
lrwxrwxrwx   1 nobody   nobody        35 Apr  6  1992 bar ->
 /usr/apps/pkgs/footool/dist/wrapper
$

Notice that the link destinations refer to the generic directory name link, footool, instead of the footool,v2.0 directory. Use the generic directory name link for each package in this way to determine the version of the package to which the commands are connected. The users start the default version of the software, and you can change the default version simply by changing the link that determines it. Alternatively, the wrapper could accept options that would enable a user to specify the version of the program to use. If the user specifies no options, the latest version is run.

You could link the command names via the specific version-named directory instead, but you would find that changing from one version to another, when that time inevitably arrives, requires more work and more exposure. This extra work might not be obvious when packages have only one or two commands, but some applications have many. FrameMaker, for instance, has more than 80 commands and all of them should be handled by one wrapper.

It is a good idea to create a help function for each wrapper to display usage information about the possible options that the wrapper command accepts. The user could then type the wrapper name with a -h (help) option to display usage information for the wrapper.