Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Before today, I've used the terminal to a limited extent of moving in and out of directories and changing the dates of files using the touch command. I had realised the full extent of the terminal after installing a fun script on Mac and having to chmod 755 the file to make it executable afterwards.

I'd like to know what /usr/local/bin is, though. /usr/, I assume, is the user of the computer. I'm not sure why /local/ is there, though. It obviously stands for the local computer, but since it's on the computer (or a server), would it really be necessary? Wouldn't /usr/bin be fine?

And what is /bin? Why is this area usually used for installing scripts onto the terminal?

share|improve this question
up vote 45 down vote accepted

/usr/local/bin is for programs that a normal user may run.

  • The /usr/local hierarchy is for use by the system administrator when installing software locally.
  • It needs to be safe from being overwritten when the system software is updated.
  • It may be used for programs and data that are shareable amongst a group of hosts, but not found in /usr.
  • Locally installed software must be placed within /usr/local rather than /usr unless it is being installed to replace or upgrade software in /usr.

This source helps explain the filesystem hierarchy standard on a deeper level.

You might find this article on the use and abuse of /usr/local/bin interesting as well.

share|improve this answer

/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/bin, /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 /usr.

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 /bin to /usr/bin and /lib to /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 /usr.

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 /usr/local default.6

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: /etc, /usr/include, /usr/share, etc.

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


  1. 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.

  2. /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 /u/$NAME.

    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 /u1/$NAME, /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.

  3. 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 root.

    Type "exit" at the single-user root prompt to leave single-user mode and continue booting into multi-user GUI mode.

  4. 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.

  5. 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.

  6. 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 curses-based software.

    (X11R6 referred to the version of the X Window System underpinning Linux GUIs for about a decade.)

  7. The original Unix systems kept their core shell scripts in /etc in order to avoid commingling them with the true binaries in /bin.

share|improve this answer

I would recommend referring to Wikipedia for structure related questions in general, it will cover the basics.

To answer your question directly, however:

  • /usr is, loosely, non-critical system libraries and executables
  • /usr/local is, again loosely, for non-system libraries and executables

This is why you tend to find similar structure between the two; /usr/{,local/}{bin,sbin,lib}. Being new to the shell, that bit with the {}'s is a shell expansion. Try executing

ls -ld /usr/{,local/}{bin,sbin,lib}

from your local shell to see how it works.

share|improve this answer

/usr/local/bin shows the UNIX-esque roots of the latest Mac OS (its BSD based under there).

  • "usr" stands for UNIX System Resources. This is the location that system programs and libraries are stored.
  • "local" represents resources that were not shipped with the standard distribution and, usually, compiled and maintained on a per site basis.
  • "bin" represents binary compiled executables.

This has morphed since the early implementations of UNIX to Linux and BSD, but the convention has stayed. Now, /usr/bin would be for "main" or core programs and libraries where /usr/local/bin would be for add-on and non-critical programs and libraries.

share|improve this answer
I've been using Unix since shortly after the Berlin Wall fell, and I'd never heard the "Unix System Resources" expansion for "usr" until today; it is a backronym. "usr" got its name because it's where the user home directories were originally located. That is, if you had a login on an old System III box, your initial working directory would be /usr/nzwulfin by default. Another common scheme. before the SVR4 /home scheme took over, was /u. One system I used early on had so many users they needed multiple physical disks for user file storage, so they had things like /u/d5/tangent. – Warren Young Nov 18 '10 at 17:54
@Warren I hadn't heard it either and poked around Google for a while; it sounds like there are quite a few backronyms – Michael Mrozek Nov 19 '10 at 23:35

/usr/local/bin is the most popular default location for executable files, especially open source ones.

This is however arguably a poor choice as, on Unix systems, /usr has been standardized in the early nineties to contain a hierarchy of files that belong to the operating system and thus can be shared by multiple systems using that OS.

As these files are static, the /usr file system can be mounted read-only. /usr/local is defeating this standard as it is by design local thus non shared, so needs to be read-write to allow local compilation and isn't part of the operating system. Too bad something like /opt/local wasn't chosen instead ...

share|improve this answer

On a Mac, while you can only write to /usr as root so Terminal, there is the way to go there in Finder. Use the "Go To Folder..."command under the "Go" menu.

share|improve this answer

I recommend you use /usr/local for commercial programs you might install such as Mathematica. Place it in its own partition when you set up. When you upgrade your OS, this partition won't be disturbed and you won't have to re-install its contents. So use it for stuff you want to keep between OS upgrades.

Separately, make sure you give /home its own partition for this reason too.

share|improve this answer

This answer might be helpful as well.


The original idea behind /usr/local was to have a separate ('local') '/usr' directory on every machine besides /usr, which might be just mounted read-only from somewhere else. It copies the structure of /usr.

These days, /usr/local is widely regarded as a good place in which to keep self-compiled or third-party programs. The /usr/local hierarchy is for use by the system administrator when installing software locally. It needs to be safe from being overwritten when the system software is updated.

It may be used for programs and data that are shared among a group of hosts, but not found in /usr. Locally installed software must be placed within /usr/local rather than /usr unless it is being installed to replace or upgrade software in /usr.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.