/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.
While both are designed to contain files not belonging to the operating system, /opt
and /usr/local
are not intended to contain the same set of files.
/usr/local
is a place to install files built by the administrator, typically by using the make
command (e.g., ./configure; make; make install
). The idea is to avoid clashes with files that are part of the operating system, which would either be overwritten or overwrite the local ones otherwise (e.g., /usr/bin/foo
is part of the OS while /usr/local/bin/foo
is a local alternative).
All files under /usr
are shareable between OS instances, although this is rarely done with Linux. This is a part where the FHS is slightly self-contradictory, as /usr
is defined to be read-only, but /usr/local/bin
needs to be read-write for local installation of software to succeed. The SVR4 file system standard, which was the FHS' main source of inspiration, is recommending to avoid /usr/local
and use /opt/local
instead to overcome this issue.
/usr/local
is a legacy from the original BSD. At that time, the source code of /usr/bin
OS commands were in /usr/src/bin
and /usr/src/usr.bin
, while the source of locally developed commands was in /usr/local/src
, and their binaries in /usr/local/bin
. There was no notion of packaging (outside tarballs).
On the other hand, /opt
is a directory for installing unbundled packages (i.e. packages not part of the Operating System distribution, but provided by an independent source), each one in its own subdirectory. They are already built whole packages provided by an independent third party software distributor. Unlike /usr/local
stuff, these packages follow the directory conventions (or at least they should). For example, someapp
would be installed in /opt/someapp
, with one of its command being /opt/someapp/bin/foo
, its configuration file would be in /etc/opt/someapp/foo.conf
, and its log files in /var/opt/someapp/logs/foo.access
.
Best Answer
And that is exactly what you are getting on FreeBSD. Shells like the Z shell and the Bourne Again shell are not part of FreeBSD. They are third-party additions. The operating system is sometimes referred to by the slang name "base". In the BSD world in general, third party additions on top of "base" do not live in
/usr
. They live in/usr/local
.In the BSD world — and this is true of other BSD operating systems like OpenBSD — you get the operating itself in
/
and/usr
, and the stuff that isn't the operating system in/usr/local
. If one wants just the operating system functionality without the additions, one takes/usr/local
out of consideration in what one is doing.The slight twist to this is that FreeBSD derivatives like TrueOS Server and TrueOS Desktop modestly consider their additions on top of FreeBSD to be not part of the operating system. So there's a whole load of TrueOS out-of-the-box stuff that lives in
/usr/local
with the non-operating-system stuff. For example: It's where you'll find PCDM, the TrueOS display manager, living.Conversely,
/usr/local
is where all custom-built softwares that are not parts of the operating system go.To show how strong this division is:
rc
scripts for non-operating-system stuff go in/usr/local/etc/rc.d/
and do not get added to/etc/rc.d/
. It's where you'll find/usr/local/etc/rc.d/nginx
./usr/local/etc/
not/etc/
. It's where you'll find/usr/local/etc/cups
./usr/share/man
where the operating system manuals are and/usr/local/man
where the non-operating-system manuals are.Even the package manager itself is (currently) not part of the operating system proper. There's a "bootstrap" package manager,
pkg-static
. This installspkg
, the actual package manager that has configuration files in/usr/local/etc/pkg
and that is itself an add-on.The conceptual leap that you have to make in coming from the Linux "distributions" world is that you don't get an operating system built by selecting from a mish-mash of packages supplied by a "distributor". You get a full operating system as one coherent unit (installed by an installer, upgraded with
freebsd-update
, and maintained as a single "boot environment" using ZFS), and all of the third-party stuff as ports and packages separate from that. If you yourself are supplying third-party stuff, be you a developer or a system administrator, then you do ports and packages too, or you just put it directly in/usr/local
somehow.On the other hand, custom-built softwares that are parts of the operating system go in
/
and/usr
where the operating system lives. The source and build system for the entire operating system come supplied in/usr/src
as part of this one self-sufficient system. You make local modifications there, share them with other people using Subversion (FreeBSD) and git (TrueOS) if you want, and rebuild either the "userland" alone or the entire operating system (both "shell" and "kernel") from that.Interesting side note
If you nonetheless make your own structure for your own machines, you are, according to the operating system manual itself, expected to provide a local
hier
manual page superseding the operating system one. ☺Further reading
hier
. §7. FreeBSD manual.