Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site watmath.UUCP
Path: utzoo!watmath!idallen
From: idallen@watmath.UUCP
Newsgroups: net.unix-wizards
Subject: Absolute vs. Relative paths: we use *one* absolute path here
Message-ID: <637@watmath.UUCP>
Date: Thu, 2-Jan-86 01:12:30 EST
Article-I.D.: watmath.637
Posted: Thu Jan  2 01:12:30 1986
Date-Received: Thu, 2-Jan-86 03:38:09 EST
References: <1016@sdcsla.UUCP> <1019@utcs.uucp> <1747@dciem.UUCP>
Organization: U of Waterloo, Ontario
Lines: 55

People who advocate setting the PATH variable and using "only"
relative path names in shell scripts are forgetting all the absolute
path names that they put in the PATH variable.  Just as commands move
from search directory to search directory, so do search directories
change, either over time or among host machines.  You can't use
hard-coded path names there, either!

We have several different UNIX systems going here, with the result that
the choice of paths in the PATH variable is not the same on all
machines.  Beyond /bin and /usr/bin, which exist on every UNIX machine
we've ever heard of, the writer of a shell script destined for
distribution to all our machines does not know where a particular
machine is keeping a command; hence, s/he cannot hard-code a particular
set of directories at the start of a system shell script.

The choices of distributing different versions of shell scripts to
different machines or making the shell scripts set their PATH by
checking which machine they are on both suffer from having the path
information for a machine replicated in the scripts.  If a machine
changes search paths, all the scripts have to be found and changed.

So, Waterloo took the leap and wrote a command, /bin/searchpath, whose
primary function is to return the list of standard search paths when
executed on a particular host.  Using arguments, the command can also
return a list of paths suitable for use by "system maintainers", people
doing "accounting", etc.  From the user's point of view, s/he selects
the type of commands s/he needs by category, and /bin/searchpath
supplies the places where they reside on the current host.  The command
provides useful detail-hiding, since the pathnames themselves are
usually anachronistic and irrelevant to shell-script programmers.

We create and maintain a file on each host that has the search path
information for that host, for use by our command.  "Porting" our shell
scripts to a new UNIX machine involves creating the file(s) containing
the search path information for that host.  New shell scripts now start
with a command to set the PATH variable: 

   PATH="`/bin/searchpath type=users`"; export PATH

These scripts work on all our UNIX systems, no matter how odd the
search path structure is at that moment.  We have a category of search
path for systems people, and it includes the "test" path(s) where we
put commands that we want to test before they get installed for real.
We are free to add, delete, and rename paths to suit our file system
space or program organization needs without requiring anyone (especially
overworked systems people) to change a single line of code.  All our new
users are supplied with login profiles that set $PATH using /bin/searchpath.

So, our shell scripts only need to know *one* absolute pathname --
/bin/searchpath.  The rest is done dynamically according to what kind
of search paths are needed and what host the script is running on.
The command requires a bit of overhead at the start of a shell script,
but, gosh, it sure makes life easier.
-- 
        -IAN!  (Ian! D. Allen)      University of Waterloo