stpeters@dawn.steinmetz (Dick St.Peters) (04/26/88)
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. The program is part of a medical imaging package that we distribute to sites that are typically new to UNIX. I don't want our software distribution to introduce poor practices like putting non-executeable files in bin directories and/or putting extraneous places into PATH. Can anyone point me to useful documentation? Even written folklore would help if it sounds authoritative or appears in many places. Please mail - I don't get to rn as often as I'd like. -- Dick St.Peters GE Corporate R&D, Schenectady, NY stpeters@ge-crd.arpa uunet!steinmetz!stpeters
wcs@skep2.ATT.COM (Bill.Stewart.<ho95c>) (04/29/88)
In article <10580@steinmetz.ge.com> dawn!stpeters@steinmetz.UUCP (Dick St.Peters) writes: > 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. ...... > I don't want our software distribution to introduce poor practices > like putting non-executeable files in bin directories and/or > putting extraneous places into PATH. Actually, it's a great practice. You might want to modify it by using some other variable such as FILEPATH instead of PATH, but it gives you the same kinds of flexibility you get with PATH - not needing to know where something is to use it, not needing to explicitly specify things when defaults are good, letting files be in multiple directories, e.g. FILEPATH=$HOME/dbfiles:/usr/local/lib/dbfiles:.: so custom versions will override the defaults. -- # Thanks; # Bill Stewart, AT&T Bell Labs 2G218, Holmdel NJ 1-201-949-0705 ihnp4!ho95c!wcs # skep2 is a local machine I'm trying to turn into a server. Please send # mail to ho95c or ho95e instead. Thanks.
allbery@ncoast.UUCP (Brandon Allbery) (05/05/88)
As quoted from <10580@steinmetz.ge.com> by stpeters@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