Using Apple Terminal
I assume you know how to use the Terminal to look around OS X. If not, then find Terminal in Applications / Utilities, go in the preferences to change the window background colours to something geekier, and have a look at one of the many Unix primers out there, like this UNIX Tutorial for Beginners from the University of Surrey. Or even better, Matisse Enzer gives away the PDF of the chapter covering the Terminal from his Unix for Mac OS X 10.4 Tiger book. The good thing about Unix - it doesn’t change that much. Those guides are still relevant.
OS X uses a simple naming convention for folder names: if they start with an upper case letter (e.g., /Users) they are Apple ones, otherwise (e.g. /usr) they are Unix. More or less.
OS X folder structure
You should be already familiar with most of these.
- Cocoa and Carbon apps. OS X applications are in fact directories that looks like files. If you list them on Terminal you can see what's in these folders, for example: `ls /Applications/Chess.app/Contents/` (you can also get to that by ctrl-clicking on the app in Finder and choosing 'show package content')
- Frameworks and components for third party applications. It also includes a /Library/Fonts folder, with all the fancy fonts installed for all users.
- Frameworks and components used by OS X. It also includes a /System/Library/Fonts folder, with the minimum set of system fonts shared by all users. If you delete any fonts from here you are in trouble.
- Users' folders, hidden from each other. And yes - they also have their own fonts folder ( /Users/username/Library/Fonts ) which are loaded up when you login as that user.
- A hidden folder that stores Spotlight's indexed metadata. Each OS X file and folder is associated with metadata - you can view it in the command line with the command mdls, e.g. `mdls ~/` You can query the metadata index created by spotlight directly on the command line with the command mdfind.
FreeBSD folder structure
Unix is an old system - when it was created every byte counted, which is why they called directories ‘usr’ and not ‘user’, to save just the one letter. It also made sense to keep what changed often and needed regular backing up separate from what changes rarely. After all, this was the equivalent of four floppy disk in those days. Mind you, that makes sense even today, as disk storage may be cheap but backing up isn’t.
- This should contain the minimum needed to boot, restore and repair the filesystem. The idea is to be able to have all the core files on small portable storage device.
- binaries used by admins and normal users. This is not the complete set of all the commands available on the system - just the minimum needed for booting and restoring (the rest are in separate places, see below). For example, in OS X 10.6 these are:
[ bash cat chmod cp csh date dd df domainname echo ed expr hostname kill ksh launchctl link ln ls mkdir mv pax ps pwd rcp rm rmdir sh sleep stty sync tcsh test unlink unrar wait4path zsh</dd>
- devices - i.e., drivers. In Unix they are setup to look and act as if they were files
- system configurations, specific for a machine. These are static, i.e. only changeable by admins, and are not executable binaries. Classic examples /etc/hosts, /etc/group, /etc/passwd
- Application packages added on. Used, for example, by MacPorts
- system binaries. These are only used by root or the system. This is the minimum set needed for booting / restoring the system. The other system binaries are in /usr/sbin and /usr/local/sbin
Typical examples include mount, reboot, fsck</dd>
- temporary files. These are deleted when the system reboots. /var/tmp is an alternative that doesn't.
- Non root hierarchy. Static, i.e. shouldn't need to change unless an admin installs something.
- This is where most commands available to all users are. There's loads and loads of them, from python to who to calendar to ssh...
- These are include libraries used by C programs. Of no interest to most users. C libraries get special treatment because at the time Unix was created C was 'the' programming language - indeed, early implementation of Unix were written in C, as opposed to assembly as it was then the norm.
- These are dynamic libraries used by packages and programs. Normally created as a side effect of installations.
- This is where software for a specific machine should go. For example mysql, php5, etc. Within this folder the same hierarchy as root holds:
/usr/local/bin for binaries,<br> /usr/local/etc for config files,<br> /usr/local/include for C libraries,<br> /usr/local/lib for shared binaries that are not exectuded directly,<br> /usr/local/sbin for system libraries run locally<br> /usr/local/share for read only libraries</dd>
- Read only files, like man pages. If you install a geo-location library like GeoIP, its data could go here
- /usr/X11 and /usr/X11R6
- This is used by the X11 - a full on Unix windows system available on your Mac. You may have come across it if using Gimp, the free Photoshop alternative. X11R6 is a symbolic link to X11
- Variable data. The opposite of static, i.e. users (or the system) change them all the time
- This is non-shareable state information for apps. Users shouldn't need to touch this
- Log files, for example from your Apache web server
- These are files related to a currently running instance of a program or package. Typically process id (.pid) files and such.
- This holds queues of data that need to be dealt with at some stage by an admin or a package. It will be typically deleted after processsing. /var/spool/mqueue holds the outgoing mail queue, for example
- This is temporary data, but unlike /tmp it is preserved between system reboots
That should give you a fair idea of what goes where, and why the Apache webserver config files are, say, in /etc/apache2/
There’s plenty information online about Unix - for example you can start from the article Filesystem Hierarchy Standard.