What is /usr/local/bin?

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.

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

/usr/, I assume is the user of the computer.

Close.

Unix started out as a multi-user operating system, so it’s not "the user," it’s "the users," plural.

Before AT&T Unix System V Release 4 (SVR4) came out in 1988 with its user management tools defaulting to creating user home directories in /home, the conventional location was /usr.¹ Your $HOME directory might have been /usr/jfw on a System III box.

/usr also contained, then as now, /usr/bin, /usr/lib, etc. Experience showed that segregating the home directories was good system management practice, so with the /home policy change in SVR4, it left behind everything we now think of as belonging in /usr.

/usr still had a good reason to hold onto the name: 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 mode² even if the /usr volume was unmountable for some reason. The root volume contained sufficient tools to get the /usr volume back online.

Several Unix flavors now disregard this old design principle since even small embedded systems have enough room for both the traditional root volume files and all of /usr on a single volume.³ Red Hat Enterprise Linux, Solaris and Cygwin symlink /bin to /usr/bin and /lib to /usr/lib so that there is no longer any difference between these directories.

…/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 should live elsewhere.

This also has roots in the way Unix systems were commonly used decades ago when all this was standardized. Again, hard disks of the time 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.⁴ 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 macOS team does this when they build, say, bash from the GNU Bash source code. They use / as the installation prefix, overriding the /usr/local default, so that Bash ends up in /bin.

Another example is the way older Linux systems segregated their GUI software into /usr/X11R6, to keep it separate from the traditional command line and curses-based software. This was done simply by overriding the default /usr/local prefix with /usr/X11R6.⁵

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 7, 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.⁶

---

Footnotes and Digressions:

1. The primitive nature of the user management tools prior to SVR4 meant that the HOME=/usr/$NAME scheme was merely documented as a convention, rather than enforced by software tools as a default.

   You can see this on page 4-8 of 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.

   It was fairly common in older Unix systems for the system administrators to choose a different scheme that made more sense to them. People being people, that meant a lot of different schemes got invented.

   One scheme I came across before /home/$NAME became the standard was /u/$NAME.

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

2. You can boot a macOS 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.

3. Unixy OSes that still appear to keep critical single-user mode files out of /usr may not, in fact, do so these days. I once rendered a FreeBSD 9 box unbootable by moving /usr to a ZFS volume. I forgot that the ZFS-on-root features didn’t land until FreeBSD 10, creating a Catch 22: the OS needed files in /usr in order to mount /usr!

   That was bad enough, but if FreeBSD 9 were still keeping its single-user boot stuff out of /usr, I could have fixed it in place. Since it wouldn’t boot even to single-user mode with /usr being unmountable, clearly that tradition had been violated somehow. I had to boot from a rescue CD to get that system back up again.

4. This is also where we get /usr/share: it segregates files that could be shared (e.g. over NFS) even between Unix boxes with different processor types. Typically, text files: man pages, the dictionary, etc.

5. "X11R6" referred to the version of the X Window System underpinning Linux GUIs at the time this convention was prevalent. Linux systems generally stopped segregating the GUI software about the time X11R6 was replaced with X.Org.

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

/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 …

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.

This answer might be helpful as well.

/usr/local

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.