The Difference Between Relative and Absolute Filenames

Specifying the location of a file in a hierarchy to ensure that the filename is unique is known in UNIX parlance as specifying its absolute filename. That is, regardless of where you are within the file system, the absolute filename always specifies a particular file. By contrast, relative filenames are not unique descriptors.

To understand, consider the files shown in Figure 3.3.

If you are currently looking at the information in the Indiana directory, Bldgs uniquely describes one file: the Bldgs file in the Indiana directory. That same name, however, refers to a different file if you are in the California or Washington directories. Similarly, the directory Personnel leaves you with three possible choices until you also specify which state you're interested in.

As a possible scenario, imagine you're reading through the Bldgs file for Washington and some people come into your office, interrupting your work. After a few minutes of talk, they comment about an entry in the Bldgs file in California. You turn to your UNIX system and bring up the Bldgs file, and it's the wrong file. Why? You're still in the Washington directory.

These problems arise because of the lack of specificity of relative filenames. Relative filenames describe files that are referenced relative to an assumed position in the file system. In Figure 3.3, even Personnel/Taylor,D. isn't unique because that can be found in both Indiana and Washington.

To avoid these problems, you can apply the technique you learned earlier, specifying all elements of the directory path from the top down. To look at the Bldgs file for California, you could simply specify /California/Bldgs. To check the Taylor,D. employee in Indiana, you'd use /Indiana/Personnel/Taylor,D., which is different, you'll notice, from /Washington/Personnel/Taylor,D..

Learning the difference between these two notations is crucial to surviving the complexity of a hierarchical file system used with UNIX. Without it, you'll spend half your time verifying that you are where you think you are, or, worse, not moving about at all, not taking advantage of the organizational capabilities.

If you're ever in doubt as to where you are or what file you're working with in UNIX, simply specify its absolute filename. You always can differentiate between the two by looking at the very first character: if it's a slash, you've got an absolute filename (because the filename is rooted to the very top level of the file system). If you don't have a slash as the first character, the filename's a relative filename.

Earlier I told you that in the home directory at the top level of UNIX, I have a home directory called taylor. In absolute filename terms, I'd properly say that I have /home/taylor as a unique directory.

To add to the confusion, most UNIX people don't pronounce the slashes, particularly if the first component of the filename is a well-known directory. I would pronounce /home/taylor as “home taylor,” but I would usually pronounce /newt/awk/test as “slash newt awk test.” When in doubt, pronounce the slash.

As you learn more about UNIX, particularly about how to navigate in the file system, you'll find that a clear understanding of the difference between a relative and absolute filename proves invaluable. The rule of thumb is that if a filename begins with /, it's absolute.

Task 3.2: Hidden Files in UNIX

One of the best aspects of living in an area for a long time, frequenting the same shops and visiting the same restaurants, is that the people who work at each place learn your name and preferences. Many UNIX applications can perform the same trick, remembering your preferred style of interaction, what files you last worked with, which lines you've edited, and more, through preference files.

On the Macintosh, because it's a single-user system, there's a folder within the System Folder called Preferences, which is a central storage place for preference files, organized by application. On my Macintosh, for example, I have about 30 different preference files in this directory, enabling me to teach programs one time the defaults I prefer.

UNIX needs to support many users at once, so UNIX preference files can't be stored in a central spot in the file system. Otherwise, how would the system distinguish between your preferences and those of your colleagues? To avoid this problem, all UNIX applications store their preference files in your home directory.

Programs want to be able to keep their own internal preferences and status stored in your directory, but these aren't for you to work with or alter. If you use DOS, you're probably familiar with how Windows solves this problem: certain files are hidden and do not show up when you use DIR, in DOS, or the File Manager to list files in a directory.

Macintosh people don't realize it, but the Macintosh also has lots of hidden files. On the topmost level of the Macintosh file system, for example, the following files are present, albeit hidden from normal display: AppleShare PDS, Deleted File Record, Desktop, Desktop DB, and Desktop DF. Displaying hidden files on the Macintosh is very difficult, as it is with Windows.

Fortunately, the UNIX rule for hiding files is much easier than that for either the Mac or PC. No secret status flag reminds the system not to display the file when listing directories. Instead, the rule is simple, any filename starting with a dot (.). These files are called dot files.

A hidden file is any file with a dot as the first character of the filename.

If the filename or directory name begins with a dot, it won't show up in normal listings of that directory. If the filename or directory name has any other character as the first character of the name, it lists normally.

Because of the particular rules of hidden files in UNIX, they are often called dot files, and you can see that I have 23 dot files and directories in my directory.

The rc suffix tells you that this file is a configuration file for that particular utility. For instance, .cshrc is the configuration file for the C shell and is executed every time the C shell (/bin/csh) is executed. You can define aliases for C shell commands and a special search path, for example.

Because it's important to convey the specific filename of a dot file, pronunciation is a little different than elsewhere in UNIX. The name .gopherrc would be spoken as “dot gopher are sea,” and .mailrc would be “dot mail are sea.” If you can't pronounce the program name, odds are good that no one else can either, so .cshrc is “dot sea ess aitch are sea.”

Other programs create a bunch of different dot files and try to retain a consistent naming scheme. You can see that .rnlast and .rnsoft are both from the rn program, but it's difficult to know simply from the filenames that .article, .letter, .newsrc, .oldnewsrc, and .pnewsexpert are all also referenced by the rn program. Recognizing this problem, some application authors designed their applications to create a dot directory, with all preference files neatly tucked into that one spot. The elm program does that with its .elm hidden directory.

Some files are directly named after the programs that use them: the .Agenda file is used by the agenda program, and .info is used by the info program. Those almost have a rule of their own, but it's impossible to distinguish them from .login, from the sh program; .plan for the finger program; .rm-timestamp from a custom program of my own; and I frankly have no idea what program created the .report file!

This should give you an idea of the various ways that UNIX programs name and use hidden files. As an exercise, list all the dot files in your home directory and try to extract the name of the program that probably created the file. Check by looking in the index of this book to see whether a program by that name exists. If you can't figure out which programs created which files, you're not alone. Keep the list handy; refer to it as you learn more about UNIX while exploring Sams Teach Yourself UNIX in 24 Hours, Second Edition, and by the time you're done, you'll know exactly how to find out which programs created which dot files.

Task 3.3: The Special Directories "." and ".."

There are two dot directories I haven't mentioned, although they show up in my listing and most certainly show up in your listing too. They are dot and dot dot (“.” and “..”), and they're shorthand directory names that can be terrifically convenient.

The dot directory is shorthand for the current location in the directory hierarchy; the dot-dot directory moves you up one level, to the parent directory.

Consider again the list of files shown in Figure 3.3. If you were looking at the files in the California Personnel directory (best specified as /California/Personnel) and wanted to check quickly an entry in the Bldgs file for California, either you'd have to use the absolute filename and enter the lengthy ls /California/Bldgs, or, with the new shorthand directories, you could enter ls ../Bldgs.

As directories move ever deeper into the directory hierarchy, the dot-dot notation can save you much typing time. For example, what if the different states and related files were all located in my home directory /home/taylor, in a new directory called business? In that case, the absolute filename for employee Raab,M. in California would be /home/taylor/business/California/Personnel/Raab,M., which is unwieldy and an awful lot to type if you want to hop up one level and check on the buildings database in Indiana!

You can use more than one dot-dot notation in a filename too, so if you're looking at the Raab,M. file and want to check on Dunlap,L., you could save typing in the full filename by instead using ../../../Washington/Personnel/Dunlap,L.. Look at Figure 3.3 to see how that would work, tracing back one level for each dot-dot in the filename.

This explains why the dot-dot shorthand is helpful, but what about the single-dot notation that simply specifies the current directory?

I haven't stated it explicitly yet, but you've probably figured out that one ramification of the UNIX file system organization, combined with its ability to place applications anywhere in the file system, is that the system needs some way to know where to look for particular applications. Just as if you were looking for something in a public library, in UNIX, having an understanding of its organization and a strategy for searching is imperative for success and speed.

UNIX uses an ordered list of directories called a search path for this purpose. The search path typically lists five or six different directories on the system where the computer checks for any application you request.

The question that arises is, What happens if your own personal copy of an application has the same name as a standard system application? The answer is that the system always finds the standard application first, if its directory is listed earlier in the search path.

To avoid this pitfall, you need to use the dot notation, forcing the system to look in the current directory rather than search for the application. If you wanted your own version of the ls command, for example, you'd need to enter ./ls to ensure that UNIX uses your version rather than the standard version.

When you learn about cd later in the book, you also will learn other uses of the dot-dot directory, but the greatest value of the dot directory is that you can use it to force the system to look in the current directory and nowhere else for any file specified.

Task 3.4: The env Command

You've learned a lot of the foundations of the UNIX file system and how applications remember your preferences through hidden dot files. There's another way, however, that the system remembers specifics about you, and that's through your user environment. The user environment is a collection of specially named variables that have specific values.

% env
HOME=/users/taylor
SHELL=/bin/csh
TERM=vt100
PATH=/users/taylor/bin:/bin:/usr/bin:/usr/ucb:/usr/local/bin:/usr/unsup/bin:.
MAIL=/usr/spool/mail/taylor
LOGNAME=taylor
TZ=EST5
%

Try it yourself and compare your values with mine. You might find that you have more defined in your environment than I do because your UNIX system uses your environment to keep track of more information.

Here we see some of the standard environment variables. Table 3.1 describes what they do.

Many UNIX systems offer the printenv command instead of env. If you enter env and the system complains that it can't find the env command, try using printenv instead. All examples here work with either env or printenv.

Task 3.5: PATH and HOME

The two most important values in your environment are the name of your home directory (HOME) and your search path (PATH). Your home directory (as it's known) is the name of the directory that you always begin your UNIX session within.

The PATH environment variable lists the set of directories, in left-to-right order, that the system searches to find commands and applications you request. You can see from the example that my search path tells the computer to start looking in the /users/taylor/bin directory, and then sequentially try /bin, /usr/bin, /usr/ucb, /usr/local/bin, /usr/unsup/bin, and . before concluding that it can't find the requested command. Without a PATH, the shell wouldn't be able to find any of the many, many UNIX commands: as a minimum, you always should have /bin and /usr/bin.

Task 3.6: Find Where You Are with pwd

So far you've learned a lot about how the file system works but not much about how to move around in the file system. With any trip, the first and most important step is to find out your current location—that is the directory in which you are currently working. In UNIX, the command pwd tells you the present working directory.

Think of pwd as a compass, always capable of telling you where you are. It also tells you the names of all directories above you because it always lists your current location as an absolute directory name.

Task 3.7: Moving to Another Location with cd

The other half of the dynamic duo is the cd command, which is used to change directories. The format of this command is simple, too: cd new-directory (where new-directory is the name of the new directory you want).

Try using a combination of cd and pwd to move about your file system, and remember that without any arguments, cd always zips you right back to your home directory.