The "official" way to add directories to your search path with HP-UX
is to list those directories in the /etc/PATH
file. They
will then be added to your shell's execution search path. And many
HP-UX commercial packages do indeed add their binary directories as
part of their installation, or else recommend that admins do it
manually. This is all very well and good, and works fine. With our
opt
structure, you can continue this process, and put
/opt/appname/bin
into /etc/PATH
as
each new application is added.
Also, packages sometimes install shared libraries. These are
typically found by searching the directories named by the SHLIB_PATH
environment variable. Again,
/opt/appname/lib
can be added to the
SHLIB_PATH value for each new application which exports shared
libraries.
However, these mechanisms can be a bit tedious. The PATH and
SHLIB_PATH variables can get quite long and unwieldy if many packages
are installed. At our site, we have hundreds of packages installed;
placing each bin
and lib
directory into an
environment variable is cumbersome. Therefore, we have added the
concept of "convenience" directories. These are directories full of
links, intended to make life a bit easier for admins and users. Their
use is entirely optional.
The main convenience directories we use are
/opt/bin
/opt/lib
/opt/man
/opt/include
(used by developers)
/opt/info
,
/opt/etc
, and /opt/share
. Convenience
directories correspond to the subdirectories in
opt/appname
directories, but contain links to
all installed applications. In general, if three or four
applications all have the same subdirectory in their application
directories, we consider making a convenience directory to gather them
together. Sometimes it makes sense, sometimes not.
The primary reason for convenience directories is to be used in search
paths. Putting /opt/bin
in the PATH variable, for
example, makes all installed applications available for execution. It
is an alternative to
/opt/app1/bin:/opt/app2/bin:opt/app3/bin:...
. The same
applies to SHLIB_PATH and /opt/lib
; developers can use
-L/opt/lib
and -I/opt/include
as a shorthand
alternative to multiple uses of those options.
The price of using convenience directories is a certain loss of
flexibility, and some cost of speed. By splitting the search path up
into multiple directories, preference can be given to one application
over another. For example, if two different apps both created a
binary named "foo"
, the PATH could select which one was
executed by placing that app's bin
directory first in the
search order. In /opt/bin
, obviously there can be only
one foo
link, so the admin must choose which binary gets
linked in. Not that search order is the best solution for a problem
like this (one or both foo
's should probably be re-named)
but the option exists. Also, larger directories are reputed to search
slower than several small directories, though in practice we have not
noticed any performance degradation from using the multiple levels of
links or the larger directories.
The links in the convenience directories described here can be created
and maintained with the repln
script, using the --app
option.
An alternative way to do convenience directories is to have "real"
copies of them only on the master opt
node, and have the
workstation convenience directories just be links to them. So, on a
workstation, you would have
/opt/bin ---> mstr/bin
This works just as well as having the convenience directories be
local.
Here is a picture of a typical workstation's /opt
directory, showing the convenience directories: