Installing Third-Party Applications
As UNIX moves into mainstream computing, third-party
come with it. As administrator, you're asked not only
to install new
applications, but to maintain them. Here are some tips
Installation instructions for major third-party applications
1. that you install them in /usr.
2. that you edit your .cshrc or .profile files to
modify your PATH variable, and to add a MY_PACKAGE_ROOT
to your environment.
Some want even more. These instructions are inappropriate
1. /usr is often overwritten by operating system upgrades.
If you install a package into /usr, you may have to
reinstall the package or restore it from dump tape after
an OS upgrade.
Moreover, /usr is the 2nd-hardest partition to enlarge
being the worst). Eventually you're going to run out
of space in /usr.
2. modifying .cshrc or .profile for everyone on the
system is not a trivial task when you've got 20, 50,
500, or more
users. Whether you do it yourself or leave some of it
to users, it
will take time to set up and more time to maintain.
Symlinks are a good idea for you -- but not for your
Yes, you can symlink the package directory, and if it
does get overwritten
at upgrade, it's easy enough to recreate the symlinks.
if you get ill, die, or find another job, tracing all
throughout all of the file systems is going to be a
pain for somebody.
Furthermore, symlinks won't help with the environment
and path modifications
that every user on the system needs.
You could put the package in a separate partition, and
mount it on
/usr. However, you get only so many partitions on a
and it's easy to run out of possible partitions as one
another is purchased.
Next point -- modifying everyone's .cshrc or .profile.
There are lots of ways to do this.
The Better Way
Put the package where you want it, and create a shell
script in /usr/local/bin
or wherever you put local software. If this directory
is already in
everyone's path, the installation is complete. The shell
in Listing 1.
/bin/sh is very portable --it's always there: that is,
it will also be there after the next operating system
Setting the package directory in this script means that
if for any
reason you have to move the directory, there's only
one file to edit.
All other files are automatically up-to-date. You fix
just one file,
not hundreds, and your users do nothing at all.
Another advantage is that you test the script, fix misspellings,
and so forth. There are no questions from users who
and can't understand why it won't work. If at the next
this application other variables are needed, or if you
a node-locked to a floating license and a new environment
has to be set, you make the change once, in this script.
make no changes.
The exec statement is very efficient. The shell passes
to the new program using the old pid. execing this
way doesn't take up extra space in the process table.
is usually small, smaller than csh or ksh, and is
often in the buffer cache anyway.
If the package includes several programs, Listing 2
shows an easy
way to deal with this. Either symlink or hard link the
to /usr/local/bin/package. `basename $0' strips
off all but the final part of the name. The case statement
into the shell, so no extra processes are needed.
You can even rationalize the name this way: instead
of having to type
SuperDataBase, you can name the script super, or db
or anything that's easy to type and easy for users to
you're in a GUI environment, have your menu exec this
too, instead of adding environment variables to the
If your users are already used to running a specific
program by a
well-known name, by all means keep that name. Or, if
the user manuals
cite a specific spelling, keep that, too, at least with
a link. (I
didn't do this on one package I installed, and every
new hire asks
me about it.)
If you don't have a local binary directory, consider
It should appear first in a user's path. The next time
a user logs
in, your script will be executed instead of the original
you're confident that everyone uses your script, you
can move the
package anywhere you want.
Listing 3 shows how to deal with a package that can
be run in several
modes. You can find a name that is meaningful to the
way your users
will execute the package, then save them typing and
to post on their terminals to get to different behaviors.
to create links to the script under all names by which
it may be invoked.
You may want to write a script to create all of the
links in case
of a catastrophe.
The shell script approach is so simple, efficient, and
I've often wondered why the third-party vendors haven't
a script in their setup or install programs. There is
no better way
to ensure that all users have the right environment
of the program.
I've used this approach again and again under SunOS
3.5 through 4.1.3,
and I plan to use it to simplify my migration to Solaris
principle is independent of the UNIX flavor you're running.
approach the next time you install a package.
About the Author
John Caywood received B.S. and M.S. degrees in computer
Old Dominion University, Norfolk, Va., and he taught
there for three years. He is currently employed by
Corporation under contract to NASA Langley Research
Center, where he
administers a network of Sun workstations and Macintoshes
Technical Editing branch. He can be reached at