lcc.bob%ucla-locus@sri-unix.UUCP (02/27/84)
From: Bob English <lcc.bob@ucla-locus> Leaving the user's path intact and giving fully qualified pathnames can cause problems for the programs exec'd by the shell. Believe it or not, some programs actually assume that the program known as "foo" actually has a specific set of options which cause a specific set of actions, whether or not the name they give it is fully qualified. Short of eliminating pathname searches at any but the command level and requiring all programs to exec fully qualified load modules, you have to set the path yourself anyway. And I'd hate to try to move a bin directory on a system that had fully qualified pathnames hardcoded into ALL of its programs (user and system). Try adding /usr/sys5 to that and retaining soe measure of consistency. --bob--
gwyn%brl-vld@sri-unix.UUCP (02/28/84)
From: Doug Gwyn (VLD/VMB) <gwyn@brl-vld> It's true that several UNIX system utilities run programs from "known" places like /bin and /usr/lib. This can be a real problem if you try to import such code and your secondary utilities have incompatible semantics. Fortunately for users of the BRL UNIX System V emulation on 4.2BSD, I took care of all these hard-wired pathnames. I would be very interested in hearing of a nice general solution (other than just standardizing everything).
usenet@abnjh.UUCP (usenet) (03/04/84)
The following might help for the system V shell, I dont know about the C-shell. If there was a command that returned the fully qualified path name of its first argument relative to the PATH given in its second argument (default $PATH) it could be used in the following way to deal with the problem of shell scripts that invoke interactive commands with PATH set to something the user is not expecting. lpath=$PATH PATH=/bin:/usr/bin:/usr/lbin real_vi=`whereis vi` PATH=$lpath $real_vi file-to-edit The 'whereis' command would look for a file named 'vi' in each of the directorys named in $PATH, in left to right order, and return the full path name of the first it found. For example, in the above script, 'real_vi' might be set to '/usr/lbin/vi' if the visual editor resided in /usr/lbin and not in any of the other directorys. Such a command would be easy enough to write, but it would be faster (hence more likely to be used when needed) if it were a shell built-in. Rick Thomas ihnp4!abnji!rbt or ihnp4!abnjh!usenet