"Proper" use of PATH and directory "purity"

[Brandon Allbery]

As quoted from <10580 at steinmetz.ge.com> by stpeters at dawn.steinmetz (Dick St.Peters):
+---------------
| A new UNIX user has written a program that looks for its configuration
| file by searching the directories in PATH.  I can't convince him this
| is bad practice, because I can't point to any documentation.  He has
| experience using DG's AOS-VS, which has a general purpose search list,
| and he dismisses my arguments as "just" folklore.
+---------------

You're welcome to use the following arguments.

If it's "just" folklore, then why did Berkeley and AT&T *both* implement
CDPATH (*not* PATH!) for a list of directories to be searched via "cd"?
Or $mail (csh) / $MAILPATH (System V) for mailbox paths?  Or, for that
matter, application paths like Informix $DBPATH, Unify 4.0 $VOLPATH, etc.?
Very simple.  The manual for sh(1) says:

	PATH	The search path for commands.

The manual for csh(1) says much the same thing (it describes the hashing
done on the path as well, which isn't relevant here).

This envariable is defined BY and FOR SHELLS.  NOT for other programs.

The reason $PATH is not to be used for general files, quite simply, is that
people expect directories in their $PATHs to contain *executables*.  It is
similar to keeping a file cabinet organized properly.  I suggest that if your
new UNIX user cannot understand or accept this than you should make sure he
does not also place folders into file cabinets out of order, etc.  This is
a major gripe I have against MS-DOS programs which insist on searching %PATH%
for their data files; it is notable that this happened only in the early days
of MS-DOS 2.x, few programs available now force users to put data files in
directories intended for executables.

Another comment:  ORGANIZATION IS NOT FOLKLORE.  ESPECIALLY NOT FOR THE
PERSON WHO HAS TO MAINTAIN THE SYSTEM.  (Which expands to the next method:
tell him that it is done that way because you/the sysadmins said so, period.
If he complains, let *him* try to keep track of things for awhile.)

You might point out to him, also, that since $PATH is defined only by shells,
it is quite possible for (say) Berkeley 4.4 or System V.4, etc. to change the
interpretation of non-executables in $PATH.  He's using $PATH in a way that is
not guaranteed by *anything*; shells do not define the interpretation of
non-executable files in $PATH directories.  Should this change, your user may
break not only his own application but also his shell -- and he has no
recourse, no way to cry "But it worked before, YOU broke it!", because he
used a feature which was not documented as being available for that purpose.

The more files in a directory, the SLOWER a shell is in searching that
directory for an executable.  Admitted, with hashing as done in both System V
and BSD shells this is not much of an issue -- except for the first time the
command is run.  If EVERY program placed its data files on the $PATH, it would
take forever to run programs.  And allowing even one program to do so creates
a dangerous precedent for other programs to do so as well.

One last comment:  The reverse of putting a data file in, say, /bin is adding
your data directory to the $PATH.  I recall that one site with a naive sysadmin
did this once.  Alas, the data directory contained a shell script "clear" which
was intended for installation and upgrading of the application in the data
directory; and on many small workstations, "clear" is also a command for
clearing the screen.  Well, one day the system "clear" program was moved from
one directory to another... and the next time a user tried to clear his screen
he instead destroyed the database.  MANY DATA DIRECTORIES ALSO CONTAIN
ADMINISTRATIVE COMMANDS INTENDED TO NEVER BE ON ANYONE'S PATH BUT ACCESSIBLE
TO SOMEONE IN THE DATA DIRECTORY!!!  This is, again, a question of correct
organization; and this is the correct organization.  It would NOT be correct
to either (a) rename the programs in question (what if they're invoked from
another compiled program?) or (b) move them elsewhere (ditto; also, they are
already in the best place!).

The paragraphs above define only a few of the reasons why $PATH is not used
as a general file search path.  They're quite enough, frankly; after destroying
your database or etc., what's left for an encore?  The moral of the story:
don't put data files or directories into your $PATH.
-- 
	      Brandon S. Allbery, moderator of comp.sources.misc
	{well!hoptoad,uunet!marque,cbosgd,sun!mandrill}!ncoast!allbery
Delphi: ALLBERY						     MCI Mail: BALLBERY