Many readers of HN won't need this explanation of the Unix/Linux/MacOS filesystem hierarchy, but for those that find it confusing here is a very brief summary. See Wikipedia for a more in depth discussion [1].<p>When Unix was invented, the concept of hierarchical filesystems wasn't new, notably Multics had a hierarchical filesystem, but there were conflicting visions. At the time, most other operating systems divided the filesystems between a number of top-level containers containing files, but no nested containers. IBM's contemporary time-sharing system, VM/370, supplied users with a set of top-level "virtual" drives each containing any number of files. There were no recursively nested directories.<p>The designers of Unix wanted a simple Operating System suitable for software development so they tended to implement an idea and then use it as much as practical in the OS design. Rather than have top-level containers like drives that contain folders that contain files, Unix just had directories and files (both implemented with the same on device structures called inodes). This combination of simple ideas fully generalized can be seen throughout Unix: multiple pathnames can point (link) to the same inode providing a form of aliasing for filenames, the api for files is generalized to include access to (possibly raw) devices so devices show up in the filesystem hierarchy, etc.<p>[/]<p>The top level directory has the name /, unlike other systems all filesystem pathnames start at this single point.<p>[/etc]<p>System configuration is found here. Most of these files are simple text files that may be edited by system administrators. In the past administrators might directly edit /etc/passwd to remove a user. Now, things are more complex, but there is still a backwards compatible /etc/passwd file (containing encrypted passwords, etc.).<p>[/bin and /sbin]<p>Unix, from the beginning was, like it's inspiration Multics, a multi-user system. Reconfiguring the system, for example to add a printer or drive, normally required running in single user mode at a privileged level. For this reason the programs needed by administrators running single user were segregated and placed in /bin. The rest of the system could be left offline, useful when working on the rest of the system.<p>As Unix grew, more and more utilities were added to /bin until it made sense to segregate it into those utilities needed when even a normal user might find themselves in single user mode vs a system administrator doing something dangerous. The super-user type programs now go in /sbin while the essential, but far less dangerous utilities go in /bin. Ordinary file copy is /bin/cp while the reboot command is /sbin/reboot. Some of the division look arbitrary to me, like /sbin/ping instead of /bin/ping, but there is probably logic behind it.<p>[/usr and /var]<p>Once booted up normally in multi-user mode, /usr contains system read-only content (for example, programs and libraries) and /var contains system content that is variable (like log files).<p>The /usr directory is large and subsequently divided into a number of second level directories.<p>[/usr/bin]<p>This is where the rest of the Unix "binaries" (i.e. programs) reside. So while ls (the list directory command) is /bin/ls the c compiler resides in /usr/bin and is /usr/bin/gcc.<p>[/usr/sbin]<p>Like the division between /bin and /sbin more administrative commands not necessary for single user mode (see /sbin) are placed in /usr/sbin. For example, the command /usr/sbin/setquota used to set disk quotas on users is in /usr/sbin and not in /usr/bin.<p>[/usr/lib]<p>This is where Unix supplied software development libraries go.<p>[/usr/include]<p>This is where Unix supplied (predominantly C and C++) include files are placed.<p>[/usr/share]<p>System documentation, the man pages, and spelling dictionaries are examples of the files found in /usr/share. They are read-only files used by the system under normal (multi-user) operation.<p>By now /usr/share is full of further subdivisions since many programs and systems need a place to put their read-only information. For example there is a /usr/share/cups for the Common Unix Printing System to store information about printers, etc.<p>[/usr/local]<p>System administrators may add additional local data and programs to their system. It make sense that these would be segregated from the rest of the files under /usr that come with Unix. The contents of /usr/local are local to the machine and are further subdivided into programs in /usr/local/bin and read-only data for these programs in /usr/local/share.<p>[/usr/X11...]<p>Once, one of the biggest subsystems in Unix was it's support for the graphical user interface known as the X window system. There were development libraries and include files, commands, man pages, and other executables. Rather than swamping the neat file hierarchy with these new files they were placed under a single subdirectory of /usr. You will probably not need to look at this very often.<p>[/home]<p>Users home directories are placed here; mine is /home/todd. Often /home is on a different physical partition so that it can be unmounted and a new version of the operating system can be installed without touching /home.<p>[/tmp]<p>Temporary files, for example that don't need to be backed up, are placed here.<p>[/mnt]<p>I've mentioned mounting and unmounting. Unix systems support a number of different filesystem formats, and devices can contain multiple filesystems (for example on distinct partitions). These filesystem become accessible once they are mounted into the hierarchy. Users need to temporarily (and now automatically) mount USB drives somewhere so that their files can be accessed via a pathname. In the past, users would just pick a directory to mount over. Now, it's traditional for temporary mounts to be placed in /mnt.<p>[/dev]<p>In Unix, low level access to devices is done through device drivers that support a number of file interfaces. Because they appear as special files they can be found under this directory. This is a convenience for programs because it makes naming and access to devices very similar to naming for ordinary files.<p>[Finding out more information about Unix and its hierarchy]<p>The Unix manual pages are a great resource. Originally, the manual was a physical book (I've still got a couple) divided into sections. Section 1 were the commands one might type on the command line. Now it is much easier to simply use the man command to access the exact same content. Use a terminal and enter "man ls", for example, to get all the information on the ls command to list directory contents. (You will be surprised at the number of options.)<p>When you aren't sure of the command's name try the command "apropos" followed by a word you'd like to find the man page for. Passwords are an important subject so "apropos password" on my system lists 47 different manual pages for information on passwords. I see one listed as "passwd(1)". The (1) means it's section one so its about a command named "passwd", the command for changing your password.<p>Here are the sections:<p>(1) Commands<p>(2) System calls<p>(3) Library functions<p>(4) Special files like device files<p>(5) File formats<p>(6) Recreations like games<p>(7) Misc info<p>(8) System admin and daemons<p>If I was looking for the format of the password file I would enter the section number 5 as the first argument to the man command: "man 5 passwd". This would show me the documentation for the password file, /etc/passwd.<p>Filesystem hierarchy manual page: "man 7 hier" or, since it is in only one section: "man hier". To find the name, "hier", of this man page one could have used the command "apropos filesystem".<p>I hope this helps; it's probably too long.<p>[1] <a href="https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard" rel="nofollow">https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard</a>