/usr/, I assume is the user of the computer.
Originally, yes, it did refer to the system's users. Before AT&T changed the default location for user folders to
/home in System V Release 4 (SVR4), the default was
/usr.1 That is to say, your
$HOME might have been
/usr/jfw on a System III box.2
/usr also contained, then as now,
/usr/lib, etc. Experience showed that segregating the home directories was good system management practice, so the default was changed, leaving behind everything we now think of as belonging in
You might think that this left
/usr without a good reason to hold onto the name, but what got left behind were files that didn't need to be available until the system was booted up far enough to support normal interactive use. That is to say, what was left behind were the user-focused parts of the OS. This meant that
/usr could be on a different physical volume, which was a good thing back in the days of 92 MB hard disk drives the size of washing machines.
Early Unix systems were careful to keep the core OS files out of
/usr so that you could still boot into single-user mode3 even if the
/usr volume was unmountable for some reason. The root volume contained sufficient tools to get the
/usr volume back online.
OS designers have started to disregard this old design principle. We have plenty of room for both the traditional root volume files and all of
/usr on even small flash disks now. Solaris and Cygwin symlink
/usr/lib so that there is no longer any difference between these directories. Linux distros such as Red Hat Enterprise Linux are following suit in recent versions.4
.../local/...obviously stands for the local computer...
Yes. It refers to the fact that files under
/usr/local are supposed to be particular to that single system. Files that are in any way generic are supposed to live elsewhere.
This also has roots in the way Unix systems were commonly used decades ago when all this was standardized. In this case, it's again because hard disks were bulky, really expensive, and stored little by today's standards. To save money and space on disks, a computer lab full of Unix boxes would often share most of
/usr over NFS or some other network file sharing protocol, so each box didn't have to have its own redundant copy.5 Files specific to a single box would go under
/usr/local, which would be a separate volume from
This historical heritage is why it's still the default for most third-party Unix software to install into
/usr/local when installed by hand. Most such software will let you install the package somewhere else, but by making a non-choice, you get the safe default, which doesn't interfere with other common install locations with more specific purposes.
There are good reasons to make software install somewhere else instead. Apple's OS X team does this when they build, say,
grep from the GNU grep source code. They use
/usr as the installation prefix, overriding the
And what is /bin?
It's short for "binary," which in this context means "a file that is not plain text." Most such files are executables on a Unix box, so these two terms have become synonymous in some circles. ("Please build me a binary for RHEL 5, Fred.")
Text files on a Unix box live elsewhere:
Once upon a time, even shell scripts — which are plain text files — were kept out of
bin directories, but this line, too, has blurred. Today,
bin directories typically contain any kind of executable file, whether strictly "binary" or not.7
See page 4-8 in the "AT&T Unix System V Release 3.2 System Administrator's Guide; here you see AT&T recommending the old
/usr/$NAME scheme in the last major version of Unix before SVR4 came out.
/usr/$NAME was never more than a convention. The primitive nature of the user management tools of the time meant that you weren't even presented with this scheme as a default, so system administrators were implicitly encouraged to choose any scheme that made sense to them. People being people, that meant a lot of different schemes got invented.
Perhaps the most common alternative before
/home/$NAME became the standard was
One system I used in the early 1990s had so many users that they couldn't fit all the home directories onto a single physical volume, so they used a scheme like
/u2/$NAME, and so on, as I recall. Which disk your home directory ended up on was simply a matter of which one had space on it at the time your account was created.
You can boot a Mac OS X box into single-user mode by holding down Cmd-S while it boots. Let go once the screen turns black and you see light gray text appear. It's like running under the Terminal, but it takes over the whole screen because the GUI hasn't started yet.
Be careful, you're running as
Type "exit" at the single-user root prompt to leave single-user mode and continue booting into multi-user GUI mode.
Unixy OSes that still appear to keep critical single-user mode files out of
/usr may not, in fact, do so these days. I recently rendered a FreeBSD box unbootable by moving
/usr to a different volume, then changing something in the system that prevented the OS from mounting that volume during boot. It wouldn't even boot into single-user mode. I had to boot the system with a rescue CD to get enough tools that I could get
/usr back online.
This is also where we get
/usr/share: it segregates files that could be shared even between Unix boxes with different processor types. Typically, text files: man pages, the dictionary, etc.
For many years, the prefix for GUI software on a Linux box was
/usr/X11R6, to segregate such software from the traditional command line and
(X11R6 referred to the version of the X Window System underpinning Linux GUIs for about a decade.)
The original Unix systems kept their core shell scripts in
/etc in order to avoid commingling them with the true binaries in