Basic Tiger Filesystem Navigation

Understanding Tiger, HFS+, and BSD Command Interaction

To the novice Unix user especially one coming from a GUI environment as nice as the Mac's venturing into the Unix filesystem will probably feel like a journey back to the Stone Age. Files upon files, nothing to indicate what any of them do, and not a friendly icon in sight. Although the filesystem might initially appear cryptic and primitive, you will find that with experience, it actually affords you considerable sophistication and control. This sophistication comes from the ability to combine the functions of many small programs into larger programs with arbitrarily complex functions.

Before the use of most Unix commands will make sense, you need to understand a few things about the design of the standard Unix filesystem, and the ways that the Mac OS X HFS+ filesystem differs. Apple doesn't strictly adhere to the model that most forms of Unix use, but from the point of view of the BSD subsystem, it functions similarly enough that almost everything works without modification. You'll find a number of differences between the way Unix thinks of files, and what you're probably used to, but after you get used to them, you'll probably find these differences are to your liking.

CAUTION

One important caution and caveat with respect to almost all basic Unix commands we're going to be covering: As you'll soon see, Unix doesn't know a resource fork from a salad fork. Apple's legacy way of storing the information for a particular file in two physically disparate locations on the disk is completely foreign to Unix, and although Apple has performed some clever kluges to allow the Mac OS X to live atop a filesystem that inherently doesn't understand portions of what the operating system is talking about, there are still some rough edges. Apple originally promised most of these would be worked out in Tiger, but as we're writing, it doesn't look like everything's quite as polished as it could be.

What you as the user will notice, as a result of these rough edges, is that it's sometimes a bad idea to use Unix file manipulation commands on files that were created by or that belong to the GUI. For example, some programs still keep their preferences in files with resource forks, and if you try to move or copy what seems to be the preferences file with the Unix command line tools, the resulting file will be damaged. Apple has provided workarounds via some specialty commands that we'll cover in several places as appropriate, but it would be nice if these fixes were melded into the traditional tools so that you didn't need to use different tools to work with different file types that's definitely not the Unix way. Even in this slightly rough state, the vast majority of things will work exactly as expected, and in four years of using Mac OS X, I've only run into a single instance in which the incompatibilities irreparably damaged a file. You should still be aware that there are some limitations, and that you should probably use the Finder for doing things such as copying, moving, and backing up critical files like applications, preferences, and documents from Cocoa/Carbon applications.

Basic Unix File Principles

Unix filesystems have a single root directory. Unlike Macintosh filesystems with their multiple drive icons on the desktop, and Windows machines with their ABCs, Unix filesystems have only a single top-level designator for the filesystem. This is the root directory named /. Unix considers all its files to belong to a tree-shaped structure, with the root directory at its base and files as the leaves. Directories are the branching points between the branches. Unix trees are upside down with respect to real trees because Unix users speak of the root directory as being at the top of the tree, and other directories and files as being under it. Any directory can contain files and other directories.

NOTE

The term root is used for multiple meanings in Unix. The root user is the most authoritative user of the system, with essentially absolute control over any process or configuration. The root of the filesystem is the top directory of the filesystem, beneath which all other files and directories occur.

Every file in the Unix filesystem has a unique and unambiguous name that points to it. This complete name is known as the full path to the file and can be specified from any directory in the filesystem to indicate any file in the filesystem. The full path to a file always starts with the root directory and ends in the filename, indicating directory names along the way, separated by the separator character /. A full path can be thought of as the shortest list of directories that must be traversed from the root to reach the file. A file with the full path /home/wizbot/spin/spinnin is named spinnin and is located in the directory spin, which is located in the directory wizbot, which is located in the directory home, which is located in the root directory /.

Files have both full paths and relative paths. A relative path is a path from the current directory, instead of from the root directory. There are two special relative directory names. One of these is ., which indicates the current directory; the other is .., which indicates the directory that is the parent of this directory. For example, assume that there is a directory named spun in the same directory as the directory named spin in the earlier path (it would have a full path of /home/wizbot/spun). If we are in the directory spun and want to specify the relative path to the file spinnin, we can do so with the relative path ../spin/spinnin. Likewise, if we're in the directory wizbot, we can use any of /home/wizbot/spin/spinnin, spin/spinnin, or ./spin/spinnin to address the file spinnin. The importance of being able to specifically address the current directory in a file path specification is probably not immediately obvious. It is related to an occasional necessity to differentiate between items in situations where there are duplicated names, and one item happens to be in the current directory.

TIP

Full (or absolute) paths always start with /; relative paths never do.

Not only do you not have multiple drives at the top level of the system (although the Finder makes it look like you do), but you, as the user, don't need to know which drives are where. Additional drives (or, more properly, partitions) appear as directories and can be mounted at any point in the filesystem to appear as an extended branch in the system. Sound strange? After a while it won't. In one of the nice feats of Unix abstraction, the system removes from the user's sphere of concern what hardware devices actually exist, and where they are or how they're connected. After you get used to this idea, you'll see that it makes really good sense. So long as you can uniquely identify a file by name in the filesystem, why would you care which spinning chunk of metal it lives on? This system has additional nice features. If you find one day that you've run out of space to put files in some particular location, you can simply add a drive to the system and mount it that is, make it appear as the directory where you need space. There's no need to reconfigure things or move files around because the additional space will simply appear as new space in whatever directory you mount it as.

If the importance of that isn't clear, imagine a situation in which you've been downloading a lot of information from the Internet. You've been storing everything in a directory named Macintosh HD/Web Stuff/Downloads, and you've just run out of space on Macintosh HD. In other operating systems, including the old familiar pre-OS X Mac OS, even if you had another disk available and ready to add to the system, you would need to rearrange things, perhaps creating Macintosh HD2/Web Stuff/Downloads and moving everything from the original directory over to the new one. With Unix-based operating systems, including Mac OS X, this is unnecessary. You would still need to move your files, but you could add the new drive and make it appear (mount it) as the directory Macintosh HD/Web Stuff/Downloads. Suddenly, that directory would have plenty of space, and you wouldn't need to rearrange the filesystem, reconfigure your Internet applications to download to a new location, or develop a new set of downloading habits.

As a matter of fact, you don't even need to know what country your files physically reside in. Again, Unix abstraction comes into play, and a remote file server is mounted as a directory under the local filesystem just as additional physical storage is. From your point of view, a remote file server is just another directory; the only difference between accessing files on it and on local storage is the possible network delay associated with transporting the files.

Regardless of whether you know where your files actually are, the shell, as previously mentioned, is always somewhere in the filesystem structure. Just like a Finder window that is showing file icons is open to and currently displaying some particular location on your system, a shell displaying a prompt is in some specific location. Commands that use files reference files from the point of view of being "in" that directory. The pwd command causes the shell to tell you what directory it's currently in.

Also as previously mentioned, Unix is a case-sensitive system, and Unix filenames are usually case sensitive from the command line. From Mac OS X, this isn't absolutely the case (depending on which base disk format you chose for your installation), but when you're working from the command line, remember that what you type must have the correct capitalization.

A file has three primary attributes that control who can access the file. These attributes control access at the level of whether the file can be read, written to, and executed. Additionally, these attributes can be specified separately for the user who owns the file, a group of selected users, and everybody on the system. These attributes can be set to any combination of values, although some combinations do not make much sense. For example, you would expect an application to be executable, a configuration file for a program to be readable, and something like your daily schedule to be both readable and writable. Unix, however, will do whatever you tell it to with the file permissions. If you make your daily schedule executable, Unix will do its best to execute it, which most likely will result in an error message and no damage done. If you tell Unix that an application is writable, it will be happy to let you edit it in a word processor, which will probably make the application useless. We cover file permissions in more detail later in the "Introduction to File Permissions" section of Chapter 11, "Using File Permissions and Access Control Lists."

Everything in the filesystem has an owner. Every file and directory in the Unix filesystem has auxiliary information attached to it that specifies the individual user who owns it, and also the group of users that it belongs to (also known as group ownership or group ID). Depending on the permissions, this user or group of users can access the file. The individual owner of the file can control the group it belongs to, and the access privileges that the group, and all other users on the system, can use in accessing the file.

Each user has a home directory. This is one special directory in the filesystem that is owned by the user and is used to contain configuration files and other content specific to the user. From the point of view of the filesystem, the user's home directory is no different than any other directory, but it is significant in that it is the directory where you start when you open a terminal and shell on the system. To make things simpler for you, Unix doesn't require that you remember the path to your directory; it can always be specified by the special path ~<username>.

Keep these basic principles in mind when reading about the commands to work within the filesystem. We cover some of them in more detail later in this chapter, but it helps to have a basic understanding of them as we move to the explanations and examples of commands.

NOTE

When discussing your interaction with the shell, we frequently use the word you interchangeably with the shell. It's much shorter to write "in the directory where you type the command" than "in the current working directory of the shell that you're interacting with when you type the command."