Joseph Kowalski wrote:
> Shawn Walker wrote:
>> I think a better way to handle it is as you suggested: only put things
>> intended for "humans to type" in /usr/bin (and thus, the PATH).
>>
> Does this imply that system administrators aren't human. I somehow
> always suspected that :-)
>
> (Please *really* note the smiley.)
>
> Seriously, are you a proponent of eliminating /usr/sbin.
Not necessarily speaking for Shawn here, but I would say that:
a) only putting things intended for "humans to type" doesn't mean
"putting all things that humans are intended to type"
b) system administrators can reasonably be expected to have /usr/sbin in
their path.
My view is that the "path" should normally be viewed as some small set
of directories:
/usr/bin: always on the path
/usr/sbin: added if the person is an administrator
/usr/X11/bin: added if the person is running in an X11 interactive
environment
/usr/openwin/bin: legacy addition that should be made a symlink to
/usr/X11/bin (IMO)
/usr/dt/bin: added if the person is running CDE
/usr/gnome/bin (hypothetical): added if the person is running gnome
/usr/ccs/bin: added for some compiler users -- but almost everything
here really belongs in /usr/bin, IMO
/usr/ucb: added only for BSD compatibility -- would like to see most of
this go away some day, or be relegated to a symlink farm to /usr/bin...
/usr/xpg{4,6}/bin: POSIX compatibility, overrides for /usr/bin where
required
/usr/lib, /usr/libexec, etc. : never on an interactive PATH
If folks choosing where to put programs could choose intelligently from
one of the above locations, a lot would self-resolve, IMO. Part of the
problem, I think, is that the aforementioned intelligence somehow seems
lacking....
Btw, I am ambivalent on the existence of /usr/games. Its not in my
PATH, in any event. :-)
-- Garrett
>
> - jek3
>
