Here’s the list of what you’ll find in /, loosely ordered from what you’ll care about the most to least:
- /home contains home directories.
- /bin contains executables (originally for binaries.) There’s also /sbin, /usr/bin, /usr/sbin, /usr/local/bin, and /usr/local/sbin.
- /media or /mnt is where temporary drives (USBs, DVDs, network shares) show up.
- /etc is where system configuration files live.
- /var is mostly used as a place applications may store files, caches, or logs. Most notable for web developers, usually /var/www is where apache looks for websites.
- /usr, /lib, and /opt are where most applications are installed.
- /tmp is used for temporary files.
- /dev, /proc, /run, /srv, /sys are all internal system things that 99% of users will never need to worry about.
Let’s use apache as an example:
- The “apache2” executable is in /usr/sbin/.
- Apache modules and such are in /usr/lib/apache2/ and /usr/share/apache2.
- System configuration of Apache is in /etc/apache2/.
Most application specific directories are named after the app.
I’m sure the actual reasons for how this structure came to be is far more historic, but I’ve come to see this directory structure to be primarily designed around segregating files by how they’re created and how often they should change.
- /home can change often, and any user change change files in their own /home directory.
- /bin, /usr, /lib, /opt, and /etc all shouldn’t change often, and should require root access to change because it’ll affect all users.
- /var and /tmp are both written to by both users and system services.
/usr/local and /opt
One of the biggest differences you’ll seem between distributions is how /usr/local comes into play. If you look inside of /usr/local, you’ll see folders called bin, sbin, etc, lib, share, and others — many which mirror the directories you’d find in /.
- Some systems (freeBSD) put nearly every app installed post launch into /usr/local. Executables will end up in /usr/local/bin, configuration in /usr/local/etc, /usr/local/share, etc.
- Others (such as Ubuntu and Debian) will only put things compiled locally (that is, not installed via a repository or such) in /usr/local.
- Some don’t even make that distinction, and hardly use /usr/local at all, just putting stuff into /usr/bin, /etc, /usr/share, etc.
A handful of applications don’t even end up in /usr or /usr/local at all and end up installed into /opt instead. /opt is where already compiled, third party applications is supposed to go. For example, when you install Google Chrome, Google Chrome isn’t compiled locally, it’s not part of Ubuntu’s repositories, so it installs to /opt.
which and /etc/alternatives
Lastly, a very helpful command when trying to track down where things are installed is which.
kevin@eisbock:~$ which -a nvim
The which command shows you where a command is. Adding the -a flag shows you all matching commands if there’s more than one. For example, I have neovim (nvim) compiled locally and installed into /usr/local/bin as well as neovim installed from Debian’s repositories in /usr/bin.
Especially if you’re digging around with which, you may run into /etc/alternatives. /etc/alternatives is effectively just a directory full of symlinks for generic commands to commands that which application you’d using to provide that generic command.
cc are both older commands and those versions are rarely installed anymore; instead, people use
gcc. However, there are symlinks in /etc/alternatives for both
cc so that scripts and people can continue to use those commands even though they’re getting a newer application behind the scenes.
x-www-browser, that’s a generic command to run the user’s default browser. There’s
editor to start the user’s default editor. Some applications like Java or PHP, are setup to install multiple versions at the same time, so you’ll find sym links in /etc/alternatives for
php specifying which version to run by default. If you ever need to change what’s in /etc/alternatives, use the