File Naming and Directory Concepts

Historically, computer systems have offered two very different kinds of user interface: a command-line based interface, and a graphical interface (GUI). In the former, users interact with the computer system by issuing commands - e.g. in the command language used on Unix systems a file called "foo.bar" might be deleted by issuing a command like the following:

rm foo.bar

while on a GUI system the file might be deleted by dragging its icon to the trash can.

Modern desktop computer systems often make both interfaces available to the user. The graphical interface is typically what computer users learn first, because it is simple and intuitive. However, being able to use a command-line interface is important for skilled users, for at least two reasons:

  1. It may be the case that there are certain tasks which can only be performed by using the command-line.
  2. For certain kinds of tasks, using the command line is quicker and easier.

This document is intended to introduce the use of the command-line interface for users who are already familiar with a graphical user interface. The examples will be specific to the computers in our Macintosh lab, running OS-X, which offers a full-featured Unix command-line interface through the Terminal application. However, the principles are equally applicable to other command line interfaces, such as that presented by Linux or the DOS interface of Windows.

File Names and Paths

Regardless of the interface that is used, every file on the computer can be uniquely specified by giving a path specification that includes the name of the file and enclosing folders (directories). If the file is located on a removeable or network volume, the path also includes information about the volume on which it is located.

For example, suppose a user in our lab mounts a network volume named "aardvark" that contains a folder named "cs211", which in turn contains a folder named "lab1", which in turn contains a file named "Lab1Main.java". Then the full name of that file would be:

/Volumes/aardvark/cs211/lab1/Lab1Main.java

In the graphical interface, one would follow this path by opening the icon for the volume "aardvark" on the desktop (where all the icons for mounted volumes appear), then opening the "cs211" folder within it, and then opening the "lab1" folder within that - which would result in the Lab1Main.java icon becoming visible. On the command line, one would specify this path by literally typing the full name given above - or by using one of the shortcuts to be discussed shortly.

The Current Directory and Relative Paths

It should be evident that having to type the full path for a file every time one wanted to access it from the command line could quickly become an unpleasant and error-prone process. One important way around this is the notion of a "current directory". When interacting with the operating system through the command-line interface, there is always a current directory. If one types a path without preceeding it by a "/", the path is taken as being relative to the current directory. For example, suppose the user's current directory were the lab1 directory (/Volumes/aardvark/cs211/lab1). Then if the user were to type a command specifying Lab1Main.java, that would be interpreted as relative to the current directory, and would be equivalent to the full path of the file: /Volumes/aardvark/cs211/lab1/Lab1Main.java. (The latter full path, which begins with a "/", is called an absolute path.)

There are, then, two important principles of interpretation of a file specification typed on the command line:

  1. If the file specification begins with a "/", it is taken as an absolute path specification beginning from the root of the directory structure on the machine. If it does not begin with a "/", it is taken as a relative path, and current directory specification is added at the front of it to produce a complete path.
  2. The meaning of a relative path always depends on the identity of the current directory. For example, if the current directory were the cs211 directory on aardvark, then the file we have been using for our examples would have to be specified by the relative path lab1/Lab1Main.java, since lab1 is not part of the current path.

In addition to the relative path specification form we have considered, it is also possible to use "../" in a relative path. The occurrence of ".." means "go up (backwards) one level in the path". For example, suppose the aardvark volume also contains a folder called cs112, which contains a file called "paper.txt". Then, if the current directory were /Volumes/aardvark/cs211, it would be possible to refer to paper.txt in either of the following ways:

../cs112/paper.txt
or
/Volumes/aardvark/cs112/paper.txt

Path Completion

Even though relative paths can save typing, there is still the matter of typing a directory or file name correctly - even a one character error, including a capitalization error, is enough to mess up the specification. To save typing, it is usually possible, while typing a file name on the command line, to press the tab key - and if the word that is currently being typed can be unambiguously expanded (i.e. only one directory/file in the current directory begins with the letters typed so far) then the command interpreter will complete the name by typing the missing characters.

For example, if one were trying to type the complete path to Lab1Main.java, it might be possible to proceed as follows:

Type /V then press tab. The system completes this to /Volumes/. Now type aa, then press tab. The system complete the partial path to /Volumes/aardvark/. Now type cs2 (c or cs alone would be ambiguous if there were also a cs112 folder on the volume). Pressing tab would cause this to be completed, yielding /Volumes/aardvark/cs211/. At this point, one might type lab1/Lab1M and press tab, which would complete the path: /Volumes/aardvark/cs211/lab1/Lab1Main.java.

Some Useful Command-Line Commands

The following are some command-line commands you will likely find useful: