For many years, the Mac OS and Unix were at opposite ends of the computing spectrum. Apple has consistently worked to make the Mac easier to use and more consistent in its methods of operation than other computers, while Unix developers…haven't. This isn't because Apple was smart and Unix developers were dumb, but rather because they had very different priorities. A little understanding of the attitudes behind Unix can help you understand the different choices that Unix developers have made, and what they achieved. The goal of Mac OS X, after all, is to unite both efforts into a consistent whole, with advantages from both sides of its heritage.
The canonical book about Unix is The UNIX Programming Environment (http://cm.bell-labs.com/cm/cs/upe/), and its title illustrates the most significant difference between Unix and the Classic Mac OS: Unix was originally intended to be a tool for programmers. This is in sharp contrast to Apple's portrayal of the Classic Mac OS as a friendly tool to bring computers to "the rest of us." Unix's designers hoped that its users would learn programming by using Unix, whereas Apple decided that users should be shielded from such "intimidating" details. Thus, while the Classic Mac OS has made a point of insulating users from the innards of the operating system, Unix has focused on providing full access to those details.
Now that Apple has officially killed off Mac OS 9 in favor of Mac OS X, Mac users have a few adjustments to make; understanding a bit about Unix can make those adjustments much more rewarding, and less frustrating.
Unix is not only different than the Classic Mac OS in the way it looks. Its very nature—the way it runs, the way it uses and manages files, and even the extent to which it trusts the user—is vastly different. I talked a bit about this in Chapter 1 when I discussed file organization and user accounts. Here are a few other things to keep in mind as you get to know the Unix side of OS X.
Unix systems are normally controlled through a shell program (discussed in more detail in the next section). Shells have two modes, interactive and scripted. In scripted mode, a shell reads a file of commands and executes them, normally without user interaction; in interactive mode, the shell accepts commands from the keyboard in real time. Both modes, however, use the same syntax and commands. This means that when you type a Unix command and press the return key to execute it, you have just written and run a one-line program. In this way, Unix breaks down the barrier between programming a computer and using a computer, and encourages normal users to become programmers.
In the Mac OS (including X), the Finder is the centerpiece. It's the fundamental program that you use to start other applications and to manage your files. In a Unix environment, including OS X's Darwin, the shell is the program launcher, but file management is delegated to other programs, including cp (copy), mv (move or rename), and rm (remove). In contrast to the Finder, the shell is deliberately kept small (300KB, versus 6MB for the Finder) to make the whole system more modular.
Carrying this further, Unix emphasizes small and flexible programs and facilitates linking them together to solve larger problems. (If you remember Apple's OpenDoc technology, now you know where Apple got the inspiration.) Unix links programs with files, pipes, redirection, and various other channels in order to accomplish more complex actions (see "Program Input and Output" later in the chapter for more on linking programs). In fact, even basic use of the command line often involves linking two or more programs.
To perform groups or series of actions, Unix systems use scripts of linked shell commands. In fact, many of the startup services I talked about in Chapter 3 are in fact sophisticated shell scripts. These shell scripts provide excellent examples for understanding and manipulating the way the system works—imagine being able to look inside a crashing extension in Mac OS 9, see the bug causing the crash, and fix it. Unix makes this feasible (although not necessarily easy).
In an attempt to shield users from the consequences of mistakes, OS X's graphical interface provides warnings before performing dangerous actions (e.g., confirmation before emptying the Trash). Unix is much less protective—it will silently allow a user to delete essential files, rendering the system unusable, so long as the user has the appropriate privileges. This is why Unix books (and Chapter 1 in this book) routinely warn about the dangers of root access, and the useful but dangerous rm -R command, both of which can wreck a Unix system if used improperly. Permissions mitigate this risk by preventing casual users from tampering with system files, and help prevent 4-year-olds from trashing vital files. By encouraging users to work in non-privileged accounts, and requiring the entry of a password to perform dangerous actions, Unix actually goes further in safeguarding certain actions, while still giving users complete control over their systems.
It may sound strange, but nearly everything is a file in Unix. What you would think of as "normal" files—a text document, spreadsheet, etc.—are very similar to files in the Classic Mac OS: sequences of bytes. However, a directory is really just a special file containing a list of files the "directory" contains. Disks and disk partitions are special files called block devices; terminals (representing user input and output) are character files, and various other useful objects, including monitors, keyboards, and running programs, are character devices. This enables the file security model (owners, groups, and permissions) I've discussed previously to manage other resources, such as shared memory and sending messages between users.
In addition, files have two separate parts: a name (also called a path), and data contained in the file. Most operating systems can have empty files that have a name but contain no data, but Unix also allows special files that contain usable data, but have no filenames, or that have more than one filename. Again, this extends the power of Unix by allowing standard file-handling code to communicate with other programs (using special files called standard input, standard output, and standard error), or the screen and keyboard. This also helps make programming easier, since powerful file management is provided "for free" by the OS, and it helps make shell programming more like interactive use, providing much of the power of AppleScript across command-line programs without requiring programmers to add special AppleEvent support.