Moving About the Unix File System

This chapter is from the book

Sams Teach Yourself Unix in 24 Hours, 4th Edition

Learn More Buy

This chapter is from the book

This chapter is from the book 

Sams Teach Yourself Unix in 24 Hours, 4th Edition

Learn More Buy

The Difference Between Relative and Absolute Filenames

Specifying the exact 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.

Figure 3.3 A simple hierarchy of files.

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 the 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.

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, there’s a folder within each user’s home directory called Library. Within that there’s another folder called Preferences, which is a central storage place for preference files, organized by application. On my Macintosh, for example, I have about 75 different preference files in this directory, enabling me to have all my programs remember the defaults I prefer.

Unix must 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: .DS_Store, Desktop DB, .VolumeIcon.icns, NavMac8000QSFile, and my personal favorite .symSchedScanLockxz. 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 (.) is called a hidden file.

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.

1. Knowing that, turn to your computer and enter the ls command to list all the files and directories in your home directory.

   % ls -F
   Archives/      Mail/          RUMORS.18Sept  mailing.lists
   InfoWorld/     News/          bin/           newlists
   LISTS          OWL/           iecc.list      src/
   %

2. You can see that I have 12 items in my own directory, 7 directories (the directory names have a slash as the last character because of the -F, remember), and 5 files. Files have minimal rules for naming, too. Avoid slashes, spaces, and tabs, and you’ll be fine.

3. Without an explicit direction to the contrary, Unix is going to let the hidden files remain hidden. To add the hidden files to the listing, you just need to add a -a flag to the command. Turn to your computer and try this command to see what hidden files are present in your directory. These are my results:

   % ls -aF
   ./             .gopherrc      .oldnewsrc     .sig        RUMORS.18Sep
   ../            .history*      .plan          Archives/   bin/
   .Agenda        .info          .pnewsexpert   InfoWorld/  iecc.list
   .aconfigrc     .letter        .report        LISTS       mail.lists
   .article       .login         .rm-timestamp  Mail/       newlists
   .cshrc         .mailrc        .rnlast        News/       src/
   .elm/          .newsrc        .rnsoft        OWL/
   %

   Many dot files tend to follow the format of a dot, followed by the name of the program that owns the file, with rc as the suffix. In my directory, you can see six dot files that follow this convention: .aconfigrc, .cshrc, .gopherrc, .mailrc, .newsrc, and .oldnewsrc.

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.

Other programs create many 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 figure out which program created each file. Check by looking in the index of this book to see whether a program by that name exists, if it’s a ".xxx" file. 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, Fourth 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 ..

I haven’t mentioned two dot directories, 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 a great deal 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, with its capability 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, 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 be in the same directory as the command and enter ./ls to ensure that Unix uses your version rather than the standard version.

1. Enter ./ls on your computer and watch what happens.
2. Enter ls without the dot notation, and you’ll instantly see how the computer searches through various directories in the search path, finds the ls program, and executes it, automatically.

When you learn about cd (change directory) later in this hour, 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 much about 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, mnemonically named values, that have specific values.

1. To view your environment, you can use the env command. Here’s what I see when I enter the env command on my system:

   % env HOME=/home/taylor SHELL=/bin/csh TERM=vt100 PATH=/home/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.

Table 3.1  Common Shell Environment Variables and What They Do

NOTE

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.