On Sun, 6 Aug 2000, Tom Rauschenbach wrote:
> Where do savvy system admins put the binaries ...
Where the package manager puts them, generally. Then we complain about the
packager endlessly. ;-)
Seriously, while (like most things Linux, or even Unix) there is no one
standard, there are general guidelines. Here's a quick rundown (pardon me if
this is review for you):
Executables (AKA binaries) live in directories named "bin" or "sbin".
Files in "bin" directories are intended (at least in theory) to be run by
anybody; files in "sbin" are system utilities and daemons.
A {bin,sbin} pair lives in the root filesystem (/), and contain everything
the system will need to get itself booted, and/or for the Local Expert to
repair things if the computer can't figure it out itself. Basics like "ls"
and "cat", "mount" and "fsck". The editor "vi" is included because it is
small; for the same reason, you don't see "emacs".
A {bin,sbin} pair lives in /usr, and contains Everything Else that came with
your "stock" system. In the traditional, commercial Unix world, /usr was
everything supplied by your system OEM; in the Linux world, /usr contains
everything supplied by your distribution vendor. There is one further
refinement: Programs for X11 live in /usr/X11/bin.
/usr/local (and {bin,sbin} under it) is for "programs local to the site".
This usually means whatever software has been installed by the local admin(s),
separate from the distro provider.
The advent of package managers like RPM and dpkg have made things slightly
more interesting. The accepted convention seems to be that files managed by
the package manager live in /usr, while files "outside" the package manager
live in /usr/local.
> Is there a system wide notion of PATH that every user can use and still
> have a local .cshrc (or what ever)?
A fairly typical user path is:
PATH=$HOME/bin:/usr/local/bin:/bin:/usr/bin:/usr/X11/bin
The "$HOME/bin" component lets the user include his or her own scripts and
programs. The search order is significant: First, check for the user's
version, then the "house" version, then finally search the standard system
$PATH. This lets the user, e.g., write their own version of "ls" with
particular defaults, etc. (The advent of shell aliases and functions has made
this useful rather then vital.)
> I mean "/usr/local/bin" still seems to me like part of the system; not
> where apps should live. What do the real pros do ?
If you are used to the Microsoft and Apple worlds, where each application
lives in its own little world (directory), the Unix model appears shockingly
disorganized at first. It really isn't. The idea is that the system should
be a working whole, not a bunch of disparate pieces. Thus, all programs are
put in one of a few "bin" directories, where they are expected to get along
and play nicely with others. :-)
Supporting libraries and platform-dependent files go in /usr/lib (or
similar), while platform-independent files go in /usr/share (or similar).
Program-specific components, not useful to other programs, are generally
placed in a subdirectory under one of these two directories.
There are a few other directories you will see (/usr/libexec for programs
invoked solely by other programs, for example, plus things like /usr/man), but
those are the most important when it comes to binaries. This structure is
replicated at several levels (/, /usr, /usr/X11, /usr/local, ...). It takes a
bit of getting used to, but (when combined with a good package manager) it has
a lot of advantages.
Okay, now that I've said all that, let me admit that there is a Unix Way to
place an application-specific hierarchy into the filesystem. The directory
/opt serves that purpose. So, you will see /opt/SuperWidget/{bin,lib,share}
or whatever.
I often combine the best of both worlds. For example, Netscape is installed
in /opt/netscape-4.74/ to make upgrades easier. I make a symlink as
/opt/netscape/ so that external paths can remains the same across upgrades.
And the "netscape" executable itself is symlinked into /usr/local/bin for
ease-of-invocation. Got all that? :-)
There is an effort underway to standardize this as much as possible. If
you've got a reasonable recent Linux system, "man hier" may get you the manual
page entitled "Description of the file system hierarchy". For even more
information, do a Google Linux Search (http://www.google.com/linux) for
"filesystem hierarchy standard".
HTH,
--
Ben Scott <[EMAIL PROTECTED]>
| "The only day wasted is that in which we have not laughed." |
| -- Chamfort |
**********************************************************
To unsubscribe from this list, send mail to
[EMAIL PROTECTED] with the following text in the
*body* (*not* the subject line) of the letter:
unsubscribe gnhlug
**********************************************************
