2.1 Section 2.1: Operating Systems

I have already mentioned Unix several times. Unix is the name of a family of operating systems, and it is important to us for three reasons. First, most people who use Emacs do so with a Unix system such as Linux (which is a type of Unix). Second, Emacs was developed — and still lives — within the Unix culture. Finally, operating systems are important, and Unix and Linux are interesting in their own right. So before we get into the details of using Emacs, I’d like to take some time to talk about operating systems generally, and Unix and Linux in particular. I’m going to start with a few basic ideas, so if you are already an experienced programmer, please be patient. Although you might already be familiar with this material, I would ask you to at least skim it, just to make sure.

Whenever a human being uses a "computer system ", there are three fundamental parts of the system that interact with one another: the computer itself, the programs that run on the computer, and the person who uses the programs. These three parts are inter-dependent :

• Computers (machines) run programs in order to perform tasks for people and provide services to other programs.

• Programs bring life to what would otherwise be inert machines.

• People use computers for a large variety of purposes, including writing more programs to run on computers.

When we talk about these ideas, we generally use more technical, impersonal terms. Specifically, we call the machines HARDWARE; we call the programs SOFTWARE; and we call the people USERS. The important idea I want you to appreciate is that computer systems are complex entities, created by a melding of hardware, software, and users. Since you are the user, you are affected by the hardware and the software that you choose to use. And, whether you realize it or not, one of the most important choices you make in your life is which operating system you will be using.¹ So let’s talk about that for a moment.

An OPERATING SYSTEM is a complex master control program that makes a computer work. Every computer, from the smallest phone to the largest supercomputer uses an operating system. Traditionally, the most important jobs for an operating system are:

1. To make efficient use of the hardware.

2. To furnish an environment for software, offering resources to the various programs as they run.

3. To provide an interface for users to interact with the software.

   Since most operating systems are bundled (packaged) with a large number of tools, we can add one more item to our list:

4. To offer a variety of basic tools (useful programs) for users.

There are a large number of different operating systems. However, the ones that you and I are likely to encounter are almost always from one of two very different families: Unix and Windows.

WINDOWS , more formally, MICROSOFT WINDOWS, is the name of a family of commercial operating systems, first released in 1985. Since then, Microsoft has created many versions of Windows to run on a large variety of different types of hardware. Windows is a commercial product, created and controlled by Microsoft. If you want to use Windows, you (or someone) has to pay for it. UNIX is a general term, referring to a large number of operating systems that are based on a large set of specific principles and specifications developed over many years. Unix is not owned by a single company. Moreover, there are many versions of Unix that are available for free.

The important thing to appreciate is that, as long as you are using a computer that has a keyboard (not a tablet, phone, or touchpad), Emacs is available — for free — to run on whatever system you are likely to be using. And (you will have to believe me here) it will be good for your brain to learn how to use Emacs.

However, before we get into the details of installing and using Emacs, I want to take some time for us to talk about Unix.

2.2 Section 2.2: Unix and Linux

Unix is the name of the world’s largest family of operating systems.

The first primitive version of Unix was created in 1969 by Ken Thompson, a programmer at the Bell Labs research facility in New Jersey, owned by AT&T.² Within a short time, Unix became popular among the Bell Labs’ and other East Coast researchers. The two main Unix pioneers at Bell Labs were Ken Thompson and Dennis Ritchie. (Their names are worth remembering.) Throughout the 1970s and into the early 1980s, Thompson, Ritchie, and other programmers expended a great deal of effort expanding and improving Unix.

In 1974, the use of Unix began to spread to the West Coast, when a computer science professor from the University of California at Berkeley visited Bell Labs and brought back a copy of Unix. In 1975, Ken Thompson went to Berkeley from Bell Labs for a year-long sabbatical. As a result of Thompson’s visit, a graduate student named Bill Joy became interested in Unix and began to work on his own version. The result was a new Unix, called BSD (an acronym for Berkeley System Distribution ), which became popular among computer scientists and programmers around the world.³ In fact, today, there are still a variety of Unix systems based on BSD, the most important being FreeBSD, NetBSD, OpenBSD, and DragonFly BSD. In addition, Apple’s Mac OS X operating system (often referred to as OS X) is, to a great extent, also based on BSD. (See the footnote in Section 2.3.)

By the early 1980s, AT&T — the company that owned Bell Labs — became increasingly impatient to start making money from Unix. To do so, in 1983, AT&T turned Unix into a commercial product called System V (pronounced "system five"). Throughout the rest of the 1980s, a large number of different Unix systems were developed, based on either System V (what we might call East Coast Unix) or BSD (West Coast Unix). The System V-based versions of Unix were commercial products, developed and sold by computer companies, including AT&T. Most of the BSD-based versions of Unix, on the other hand, were non-commercial and were distributed for free.⁴ In this way, BSD gathered a large following of computer scientists, researchers, and programmers around the world.

By 1991, personal computers had been around for 10 years, and many programmers now had their very own computers. (The IBM Personal Computer was introduced in August 1981.) However, there was still no operating system that ran on a PC that was attractive to the type of programmer whose idea of fun was to take things apart and modify them.⁵ Nevertheless, the world was ready. What follows is a long, interesting story, very much related to Emacs. However, in the interest of brevity I will shorten it.

In 1985, Richard Stallman started the Free Software Foundation (FSF) . As we discussed in Section 1.4, one of Stallman’s goals was to create a free version of Unix — which he named GNU — that would be available to anyone who wanted to modify, use, or distribute it in any way. Nevertheless, by 1991, GNU was not nearly ready. To explain what happened next, I have to make a quick technical digression. However, it’s an important digression, so stay with me.

As we have discussed, operating systems such as Unix are very complex. To simplify a bit, the basic functionality of a Unix system is provided by two different parts: the kernel and the utilities. The KERNEL, which is always running, is the central part of the operating system. As such, it provides essential services as they are needed. The UTILITIES consist of a wide variety of separate programs, distributed along with the kernel as part of the entire system. Where the kernel is the heart of an operating system, the utilities provide functionality to the users and to other programs. To summarize:

Kernel + Utilities → basic operating system

Unix Kernel + Unix Utilities → basic Unix system

Modern Unix systems come with, literally, hundreds of different utilities, each of which provides a different function. The most important utility is the SHELL — also known as the COMMAND PROCESSOR — the program that provides the primary user interface into Unix. The job of the shell is to process Unix commands as they are entered by a user. The shell can also process a list of commands stored in a file, called a SHELL SCRIPT . Over the years, there have been a variety of different Unix shells. Today, the most popular shell — the one you will probably use — is called BASH.⁶ (In Section 2.7, we’ll talk about how to enter commands for the shell.)

To return to our discussion: By 1991, the world was ready for a completely free operating system that programmers could run on their own PCs for fun, for experimenting, and to modify and share — without cost — with other programmers around the world. (The Microsoft and Apple operating systems, Windows and Mac OS respectively, didn’t fill this need because they were — and still are — purely commercial products that are kept under tight control by the companies that own them.) To be sure, the FSF had done a lot of work towards creating an open version of Unix for personal computers. By 1991, they had created a great deal of high-quality, free software, including many of the traditional Unix utilities (and Emacs). However, the FSF did not, as yet, have a kernel. And until such a kernel was created, there would be no free Unix system for PCs.

However, on August 25, 1991, Linus Torvalds (Figure 2-1), a second-year computer science student at the University of Helsinki (Finland) announced via Usenet,⁷ that he was developing his own freely shared Unix-like kernel for PCs. Torvalds started this project just for fun, and asked for volunteers. He realized that all he really needed was a kernel, because the FSF had already created a free version of the most important Unix utilities, which he could adapt easily to his own system.

Figure 2-1. Linus Torvalds, 2004. Linus Torvalds (1969), the original creator of the Linux kernel. In 1991, Torvalds founded the project that resulted in the first-ever, free Unix kernel. Torvalds combined his kernel with the Free Software Foundation’s utilities to create Linux, the first free Unix system for personal computers. Today, there are a very large number of different Linux systems, running on virtually every type of computer.

In September 1991, Torvalds and his collaborators released the first-ever free Unix kernel to run on a PC. It was then a relatively easy job to adapt the FSF utilities to work with the new kernel, giving birth to a brand new version of Unix, which came to be known as LINUX. Linux is free,⁸ open source software, licensed primarily under Version 2 of the GNU General Public License (GPLv2). (We discussed the GPL in Section 1.5.)

Today, there are many, many different versions of Linux — often referred to as Linux DISTRIBUTIONS — running on virtually every type of computer: from tiny computers that are smaller than your hand, to the largest supercomputers.

2.3 Section 2.3: Unix Terminals and Userids

In Section 1.4, I told you that the most popular type of Emacs is GNU Emacs, and that it runs under a variety of different operating systems, including Microsoft Windows. However, almost everyone who uses Emacs does so under some type of Unix. Specifically, GNU Emacs is available in specific versions for Linux, FreeBSD, NetBSD, OpenBSD, Mac OS X,⁹ and Solaris. For this reason, I am going to assume that there is a good chance that you, too, will be using Emacs on a Unix system. To prepare you properly, there are important Unix concepts I want to make sure you understand.

What we are about to cover in the rest of this chapter is particularly relevant to learning how to use Emacs skillfully. However, it is, necessarily, a brief, abbreviated overview of Unix. There is a lot more to learn and, unfortunately, I am not able to cover it all in this book. The best way to learn how to use Unix/Linux well is to read my book Harley Hahn’s Guide to Unix and Linux.¹⁰ As you read this chapter, you might wonder, is all this really necessary? The answer is, yes. I can assure you that people who are skilled at using Emacs know everything I will be covering. Please take the time to read through all the material.

To start, I'll remind you that Unix was developed in the 1970s (see Section 2.2), before programmers were able to have their own personal computers. To work with Unix, a person would use a terminal to connect to a host. The TERMINAL was an electronic box with a keyboard and a screen, or a keyboard and a printer.¹¹ The HOST was the computer to which the terminal connected. The connection could be either via a cable (which was relatively fast), or via a modem and telephone line (which was very slow). Such terminal/host systems were called TIME-SHARING SYSTEMS or MULTIUSER SYSTEMS , because they could support multiple users who were "sharing" the computer’s time, so to speak.

Thus, from the very beginning, the architecture of Unix was based on a terminal/host time-sharing system and — believe it or not — that is still the case today. I want to spend a moment talking about this paradigm because it will help you understand what happens when you use Unix in general and Emacs in particular.

Let’s pretend for a moment that we are going to take a time-travel trip back to the late 1970s. Close your eyes and pretend that it is 1976, and you and I are visiting the computer science department at U.C. San Diego.¹² We want to use one of the Unix systems so we visit the SYSTEM ADMINISTRATOR, the person who runs the system we want to use. The system administrator sets up a Unix account that will enable us to use the system. The ACCOUNT includes a variety of information including a userid and a password.

A USERID (pronounced "user-eye-dee") is a one-word name, usually all lowercase, that is used to identify a user to the system. A PASSWORD is a (hopefully) difficult-to-guess series of characters that provides security for a particular userid. Passwords are secret; userids are not.

As an example, let us say that the system administrator gives us the userid harley and a password kajsaanka. ¹³ Whenever we want to use Unix, we must find a terminal and identify ourselves to the system. To do so, we LOG IN by typing our userid (so the system knows which account we will be using), followed by our password (to prove that we are allowed to use that account).

After logging in, we can now make use of the Unix system by entering commands. As we discussed in Section 2.2, the program that interprets our commands is called the shell. Each time we log in, a shell is started for us automatically. It then sits there quietly, waiting to serve us. We enter commands, one after another, and when we are finished using the system, we LOG OUT by terminating the shell. We do this by entering the logout command, or by pressing a special key combination (<Ctrl-D>) to tell the shell there are no more commands.¹⁴ Once we have logged out, someone else can use the terminal.

Aside from keeping track of our userid and password, our account also specifies what level of privileges we are allowed to use. Generally speaking, there are two types of userids: the system administrator’s and everyone else’s. The system administrator has a special userid with its own password that allows him to do anything he wants. When a person logs in using this userid, we say that he or she becomes SUPERUSER. To protect the integrity of the system, all the other accounts have restricted privileges: they are able to use the system for regular work, but they do not have enough power to cause harm to the system or to other people’s files. Being superuser is so powerful that it must be used sparingly to protect the integrity of the system and to keep everyone’s files safe.

Typically, a system administrator will use a regular account for his own personal work. He or she will only use the superuser account when absolutely necessary. In our example, when we asked the system administrator for a Unix account, he would have paused what he was doing, logged in as superuser, created a new account for us, and then logged out as superuser.

So that is how it worked in 1976. To use a Unix system, we had to ask the system administrator to create an account for us, with a userid and password. We then had to find a terminal attached to that system, and log in. We would use the system by typing commands, one after the other, which would be processed by the shell. When we were finished, we would log out. If something important had to be done that required special privileges, the system administrator was required to log in as superuser, at least long enough to carry out that particular task.

The reason I am telling you all this is because — believe it or not — decades later, Unix still works the same way. And since Emacs developed within a Unix environment, the Unix way of thinking is deeply connected to the Emacs way of thinking.

Consider the following metaphor. Let’s say you want to learn how to speak a new language. Ideally, you want more than to simply speak the language; you want to speak it without an accent. It’s the same with Emacs. No matter what operating system you use to run Emacs; no matter how much time you spend with it; no matter what you use it for — if you don’t learn basic Unix, you will never be able to speak Emacs without an accent.

Eventually, this will all make sense. For now, just trust my judgment and keep reading as we move towards our next goal: to discuss the various environments ("user interfaces") that you can use to run Emacs. However, for that discussion to make sense, we first need to take a few minutes to talk some more about terminals.

2.4 Section 2.4: Types of Terminals

The very first computer terminals, dating from the 1960s, were PRINTING TERMINALS that printed their output on paper: either a continuous roll or a stack of folded, perforated pages (called COMPUTER PAPER). You can see two such terminals in the photo in Figure 2-2. This photo, taken around 1970, shows Dennis Ritchie and Ken Thompson working on a PDP-11 computer at Bell Labs. It is likely that this is the very computer used by Ritchie and Thompson to create the first version of Unix.

Figure 2-2. Dennis Ritchie (standing) and Ken Thompson (sitting), circa 1970. This photo, taken at Bell Labs sometime around 1970, shows Dennis Ritchie (1941-2011) and Ken Thompson (1943-). Ritchie and Thompson, the original developers of Unix, are working on a DEC PDP–11 computer. The terminals that Thompson is using are Teletype Model 33 ASRs.

By the early 1970s, printing terminals were being replaced by VIDEO DISPLAY TERMINALS. Instead of using paper, video display terminals displayed their output on a built-in monitor. The terminal worked with a set number of rows, and each new line of text was written to the bottom row of the monitor. As this happened, all the other lines were moved up one row, while the (old) top line disappeared.

The DEC VT52 terminal (introduced in July 1974) had 24 rows, each of which could display 80 characters. A few years later, the VT52 was replaced by a more powerful terminal, the DEC VT100 (August 1978), which displayed either 24 rows of 80 characters or 14 rows of 132 characters.¹⁵ Since this type of terminal can display only characters, we refer to them as TEXT TERMINALS. You can see a photo of a VT100 in Figure 2-3.

Figure 2-3. VT100 terminal. The DEC VT100 terminal was introduced in 1978 by the Digital Equipment Company. In the late 1970s and early 1980s, these VT100 family of terminals were very popular. To this day, their basic characteristics are preserved in most terminal emulators.

As I mentioned, the original video display terminals displayed new data only on the bottom row, causing all the lines to move up (similar to a printing terminal). However, as text terminals were improved, it became possible for the software to display or erase characters in any position on any row. This meant that programmers now had more choices. Instead of simply displaying output on the bottom line — causing all the other lines to move up — terminals such as the DEC VT100 made it possible for programs to use the entire screen at once, typically 1,920 separate characters (24 lines x 80 characters/line). This enabled programmers to create a new type of interface. We’ll talk about the details in Section 2.5. For now, I’ll just say that this is the type of interface that was used to create Emacs.

Over the years, better and better video display terminals were developed: not only text terminals but, eventually, GRAPHICS TERMINALS that could display both text and images. A few of the more widely used graphics terminals were the IBM 2250 (introduced in 1964), the DEC GT40 (1972), the IBM 3270 (1977), the Textronix 4010 family (1972-1974), and the latecomer DEC VT240 (1984).

Graphics terminals were important because they made it possible for programs to display images, lines, curves and other shapes, as well as plain text. Graphics terminals also made it possible to share graphical programs over a network, a capability that was especially important to universities and research organizations. However, compared to text terminals, graphics terminals were very expensive and required much more complicated software to connect to a host computer. One reason was that every type of graphics terminal had its own distinctive requirements, and it was a lot of work to make even a simple program work with different types of graphics terminals. This is because displaying graphical output requires special-purpose hardware and extra computing power.

In the late 1980s, however, these limitations began to change because of an ambitious and, ultimately, very successful project called X Window, started at MIT in 1984 by Bob Scheifler and Jim Gettys. At the time, there were many MIT programmers, using a large variety of different types of hardware. What X WINDOW offered was a standard way for people to use the keyboard, monitor and mouse on their own computer to interact with programs that were running on any computer in their network. Moreover, X Window offered portability. Once a program was written to work with X Window, it could be used by anyone whose computer had X Window software.

Because personal computers with graphics capabilities were now readily available, it wasn’t long before computers running X Window obviated the need for expensive, complex graphics terminals. Within a short time, X Window became an industry standard that, over the next few years, led to a revolution that would change forever the way most people used their computers.

What fueled this revolution was the growing realization that it was not the case that people interact with hardware. Rather, people use hardware to interact with programs. Although this might seem obvious to you now, this idea was an important insight that took years for people to appreciate. Why this was so important and, specifically, how it influenced the development of Emacs, is the topic of Section 2.5.

2.5 Section 2.5: User Interfaces

On August 12, 1981, at the Waldorf Astoria ballroom in New York City, an event occurred that would, in retrospect, be recognized as changing the world. At an IBM press conference, an executive named Phil Estridge announced the brand new IBM 5150 computer, nicknamed the IBM Personal Computer or IBM PC. Since the late 1970s, other companies had been making relatively inexpensive computers to be used exclusively by one person at a time. The most popular machines were the Commodore PT, Apple II, TRS-80 and Atari 400. However, IBM was, by far, the largest computer company in the world, and it wasn’t until they finally announced their own personal computer, along with a new set of industry standards, that the age of personal computing finally began.

By the end of the 1980s, personal computers became more affordable and more powerful, and Unix programmers had shifted from using terminals to using their own computers. Specifically, many people were using Unix on inexpensive IBM PC COMPATIBLE personal computers, machines that adhered to standards based on the IBM PC family. Other people, who needed more power and larger monitors, used expensive, high-end Unix machines called WORKSTATIONS.¹⁶

Remember, however, Unix had always been a multiuser, terminal/host time-sharing system (and it still is). As we discussed in Section 2.3, in the early 1980s, to use Unix you needed a terminal to access a Unix host. But with a personal computer, all the hardware is part of a single machine. So the question arises: When you use Unix on your own computer, where is the terminal and where is the host?

The answer to this question involves two important inventions: "terminal emulators" to use with text-based programs and "graphical user interfaces" to use with graphics-based programs. We’ll start with the text-based programs.

When you run a text-based program on your own Unix computer, even today, you need a terminal to connect to a host. That’s the way Unix was designed in the early 1970s, and it has never been changed. As you might guess, your computer is the host. But where is the terminal?

Obviously, you don’t use a real terminal. Instead, you use a special program that utilizes your computer’s keyboard and monitor to simulate the functionality of a terminal. In this way, you can log in, enter as many commands as you want, run as many programs as you want, and log out, just as if you were using an actual physical terminal.

When a program simulates the functionally of a physical device, we say that it EMULATES that device. So a program that acts as a terminal is called a TERMINAL EMULATOR. There are many different terminal emulators in use today and, believe it or not, they are all based on the old DEC VT100 family of terminals we discussed in Section 2.4. This means that, even today, when you type a Unix command or run a text-based Unix program, you are using a technology that was first introduced in 1978.¹⁷ Moreover, as far as Unix is concerned, the terminal/host system is working just fine, the way it has always worked, because your programs don’t know whether you are using a terminal emulator or a real terminal. This concept is important because the underlying technology has a strong influence on how you interact with your programs. Let me be more specific.

To communicate with a program that is running, we use what is called a USER INTERFACE. There are two basic text-based interfaces, which means that there are two different ways in which you might find yourself working with text-based programs. (Graphics-based programs work differently, as you will see in a moment.)

The simplest text-based interface is the COMMAND-LINE INTERFACE or CLI. When you use a CLI, you type one line at a time and then press the <Enter> (or <Return>) key. As you type, the characters are displayed on the bottom line of the screen. When you press <Enter>, whatever you have typed is sent to the program, and all the lines on the screen scroll up one row. In the same way, when a CLI-based program writes output for you to read, it does so one line at a time on the bottom line of your screen. As each line is displayed, all the other lines scroll up one row.

When you use a CLI, you use only a keyboard for input, not a pointing device. The most common example would be typing Unix commands, one at a time, for the shell to interpret. (This is where the name "command-line interface" comes from. The bottom line of the screen where your input is displayed is called the COMMAND LINE.)

The second text-based interface is more sophisticated. It is called a TEXT-BASED USER INTERFACE or TUI. With a TUI, a program can read and write characters anywhere on the screen, not just on the command line. As a result, TUI-based programs have a different look and feel: they take over the entire screen, so you have the feeling that you are working "within" the program. The more sophisticated TUI programs may display colors, and will use the various parts of the screen in different ways. For example, a TUI-based program may arrange data into columns, or even create rudimentary windows.

Some TUI programs will let you use a mouse, most commonly to access simple menus to make selections. Still, with a TUI-based program, pull-down menus are generally not very important. Most of the time, you will be using your keyboard to control the program, which means that you will need to memorize a lot of different commands. The reason I am telling you all this is because Emacs is a TUI-based program. In fact, it is one of the most powerful TUI-based programs ever written.¹⁸

When you work with graphics-based programs, you use a GRAPHICAL USER INTERFACE or GUI, which is a lot different than a CLI or TUI. A GUI manages the entire screen, or multiple screens if you have more than one monitor. With a GUI, you typically run multiple programs at the same time, each program in its own window. Whenever you change to another program — usually by clicking on its window — we say that you move the FOCUS to that program. (At any moment, the program that has the focus is the one that reads the input from your keyboard.)

When you use a GUI, you will see all the typical graphical elements: windows, icons, menus, scroll bars, buttons, and so on. The background on which these elements appear is called the DESKTOP. (For example, you might say, "I have three windows open on my desktop.") For this reason, a GUI-based working environment is often referred to as a DESKTOP ENVIRONMENT. More specifically, a desktop environment refers to the design of all the graphical elements, how they work, and how they interact; as well as all the tools that are included as part of the GUI package, such as a file manager, a terminal emulator, tools to help you change your system’s settings, and much more.

When you install Linux, you create a master account by specifying a userid and password. Each time you start Linux, you will be asked to enter your userid and password, at which point the GUI will start automatically. In the world of Unix, there are many GUIs, but they are all based on the X Window system we discussed in Section 2.4. With Linux, the most popular GUIs are Unity, Gnome and KDE.¹⁹ Each of these GUIs has its own desktop environment. However, because they more or less follow the same general principles, if you can use one, it’s not hard to learn how to use another.

When you use a CLI or a TUI, you control a program by typing at it. With a GUI, you do use your keyboard, but mostly to enter data. Generally, you control your programs by using a pointing device, such as a mouse, trackball, touchpad, or pointing stick. For example, you would use a pointing device to pull down menus and make a selection; to manipulate objects by dragging and dropping; and so on.

Now back to Emacs. Every time Emacs starts it checks what type of interface you are using and acts appropriately. If you start Emacs while you are working within a GUI, Emacs runs as a graphics-based program inside a window. If you start Emacs from a text-based terminal, Emacs takes over the terminal’s screen and runs as a TUI program. Nevertheless, no matter what system you are using (Unix, Windows, or Macintosh) and regardless of how you run the program, Emacs always works the same. Here is why.

Like so many other enduring programs, Emacs is a product of the times during which it was created. To be sure, over the decades, Emacs has been rewritten more than once and enhanced many, many times. Still, the program remains surprisingly close to its roots, and if you really want to understand it you need to have a sense of the historical conditions under which it arose.

Emacs was designed to work well with the hardware and software limitations of its time and, in the environment in which Emacs was developed, people interacted with programs by typing one command after another.

Realize then, that when you use Emacs today you are, literally, copying the keystrokes of programmers who, decades ago, decided which key combinations worked best for what they wanted to do. This is important to remember so when you set out to learn how to use Emacs, you don’t think that what you are learning is unnecessarily complicated and arbitrary. Emacs is well-designed and, I promise you, you will see that, but it will take a while. Along the way, if you ever get discouraged or confused remember what I told you in Section 1.1: Emacs is difficult to learn, but easy to use.²⁰

For this reason, no matter where and how you run Emacs, you will always control the program by typing at it — and the key combinations will always be the same. This means that the Emacs skills you learn from this book will last you forever.²¹ That’s the way it was designed back in the late 1970s (see Section 1.4), and the design still works well. Emacs is, arguably, the best TUI-based program ever written, and there is no need to change it. Indeed, changing Emacs from a text-based, command-driven program that requires you to learn a huge number of key combinations into an "easy-to-use", GUI-based program with icons and menus would be like sending Donald Duck to charm school.²²

2.6 Section 2.6: Using a Unix Terminal

So far, we have discussed why the terminal/host system is a basic part of Unix (Section 2.3) and why you need a terminal to work with text-based programs (Section 2.5). The most important such program is the shell, the command processor that reads and interprets your commands (Section 2.2). Because the shell is a text-based program , you need to have access to a terminal in order to use Unix commands. You also need access to a terminal to use Emacs.

The specific details I am about to show you below are based on Ubuntu Linux , a very popular Linux distribution. However, most of what you read here will work with all Linux systems, and the general ideas apply to any type of Unix.

As we have discussed, no one uses real terminals anymore. Instead, we use terminal emulators. So whenever you hear people talk about a "terminal", you can assume that they are referring to a terminal emulator, not a real terminal. For example, if I say, "I am going to show you how to use a Linux terminal", what I mean is, I am going to show you how to use a Linux terminal emulator.

There are two different types of terminal emulators : virtual terminals and terminal windows. When you use a VIRTUAL TERMINAL , the terminal emulator uses your entire screen to provide you with a totally text-based experience. When you use a TERMINAL WINDOW, the terminal emulator runs in a window within a GUI (graphical user interface).²³

Linux systems come with six built-in virtual terminals (and you can create more if you need them). To access the six built-in terminals, you use the key combinations shown in Figures 2-4 and 2-5.

Figure 2-4. Accessing a Virtual Terminal From the GUI. To switch from the GUI to aspecific virtual terminal, use <Ctrl-Alt-F1> through <Ctrl-Alt-F6>. To return to the GUI, use <Alt-F7> or <Ctrl-Alt-F7>.

Figure 2-5. Changing From One Virtual Terminal to Another. To switch from one virtual terminalto another, you have several choices. <Alt-Right> changes to the terminal with the next highest number. <Alt-Left> changes to the terminal with the previous number. <Alt-F1> through <Alt-F6> changes to a specific terminal. Finally, <Alt-F7> will return you to the GUI (the Desktop Environment). Please note that, for convenience, the function key combinations can use either <Alt> or <Ctrl-Alt>.

To use a virtual terminal, you must log in by typing your userid and your password. To log out, you can either use the logout command, or press <Ctrl-D> to send an eof signal. (We will discuss signals and eof in Section 2.11.)

The advantage of using a virtual terminal is that it looks and works pretty much the same as if you were using a real terminal. Specifically, the display is all text and uses the entire screen, which makes the characters easy to read. Moreover, there are no windows or icons or other elements to distract you, so it is easy to focus on one thing at a time.

You can switch from one virtual terminal to another by pressing the appropriate key combination.²⁴ For example, let’s say you are working with the GUI and you want to use virtual terminal #1. You would use:

<Ctrl-Alt-F1>

After a while, you want to pause what you are doing to use a different virtual terminal. To switch to virtual terminal #2:

<Alt-F2>

Later, you decide to switch back to virtual terminal #1. Either of the following will work:

<Alt-Left>
<Alt-F1>

Finally, you decide to switch back to the GUI (which will be exactly how you left it):

<Alt-F7>

The second way to access a terminal is by using a terminal window . Unlike virtual terminals, terminal windows run within the GUI in their own window, like regular programs. The advantage of using a terminal window is that, as you work, you are within the GUI, so you can use all the other GUI-based tools that are part of your desktop environment. You can also have multiple windows open, each with its own program. If you want to work with more than one terminal at a time you can open more than one terminal window and, because everything is running within the GUI, you can copy and paste between a terminal window and any other window. (This is not the case with virtual terminals. Because each virtual terminal runs in its own environment, you can’t copy and paste from one virtual terminal to another; and you can’t copy and paste from a virtual terminal to the GUI, or from the GUI to a virtual terminal.)

Starting a terminal window is easy. However, before I give you the instructions, I want to take a moment to give you a brief introduction to the Ubuntu GUI and the default desktop environment, named Unity (see Section 2.5).

The Unity desktop environment (see Figure 2-6) is particularly easy to use. The column of icons on the far left (under the words "Ubuntu Desktop") is called the LAUNCHER. You use the Launcher to start programs. The top icon in the Launcher is the Ubuntu logo. You click it to open the DASH, a tool that lets you search for anything you want.

Figure 2-6. The Ubuntu Desktop. The default Ubuntu desktop environment, Unity, is particularly easy to use. The column of icons on the left, under the words “Ubuntu Desktop”, is called the Launcher . It is used to start programs. For example, to start a terminal window, just click on the Terminal icon. To start Emacs (once it is installed), click on the Emacs icon. The top icon in the Launcher is the Ubuntu logo. You can click it to open the Dash, which enables you to search for anything you want.

The easiest way to start a terminal window is to click on the Terminal icon in the Launcher (see Figure 2-6). Clicking on this icon will open a program (a terminal emulator) called TERMINAL inside a window of its own. If you want to start another, separate terminal window, just right-click on Terminal Icon and select "New Terminal". In this way, you can start as many terminal windows as you want.

If for some reason you don’t see the Terminal icon in the Launcher, it is easy to find. Click the top icon on the Launcher to open the Dash and then type "terminal". You will see the Terminal icon, which you can click to start the program.²⁵

2.7 Section 2.7: The Unix Command Line

The COMMAND LINE is a facility provided by an operating system that enables you to enter commands, one at a time. These commands are then processed by the shell (see Section 2.2). The command line is important because it enables you to use many of the tools that come with your operating system. (These tools are the "utilities" we talked about in Section 2.2.) When you use Unix, these tools are referred to as UNIX COMMANDS. With Windows, they are called WINDOWS COMMANDS.

As a smart person who wants to use his or her computer well, it behooves you to master the intricacies of the command line. In addition, it will help you to understand how to use the more important Unix commands (tools). As an Emacs user, it is especially important, because you can access the command line from within the Emacs environment, which makes it possible to use any of the commands you want — and there are hundreds of them — without having to leave Emacs. Before that can happen, however, you need to understand how to use the command-line on its own.

To use the command line well requires a lot of knowledge and takes a lot of experience, so I can’t teach you everything right now. What I can do is make sure you know the basics, at least enough to get you started. If you are an experienced programmer, you may already know what I am about to explain. If so, it’s probably better to not skip this part of the book. (Just read it quickly. Who knows, you may find something that is new to you.)

In the next few sections, I am going to show you how to use the Unix command line. What you are about to read will work for any type of Unix, including Linux and Mac OS X. If you use Windows, the basic ideas will be the same, but the details and the commands will be different.²⁶

To access the command line, you must be using a terminal. If you are using Linux, just follow the directions in Section 2.6 and open either a terminal window or a virtual terminal. With a terminal window, you will be logged in automatically. With a virtual terminal, you will have to enter your userid and password to log in manually.

2.8 Section 2.8: The Shell Prompt

As you use a terminal, the shell will indicate when it is ready for you to enter a command. It does this by displaying a special series of characters called the SHELL PROMPT. Every shell has a default prompt, which you can change if you want. Here is an example using Bash on one of my Linux systems:

harley@kajsa:∼$

Although you can’t see it, there is a space after the $ (dollar sign) character. The space is there to create a bit of room between the prompt and the command you will be typing. For example, if you were to type the date command (to display the time and date), it would look like this:

harley@kajsa:∼$ date

By convention, the second-last letter of the prompt (before the space) identifies the type of shell. Broadly speaking, there are two main families of shells in common use: the Bourne Shell family and the C-Shell family. If your shell is a member of the Bourne Shell family, you will see a $ character, as in the examples above. If your shell is a member of the C-Shell family, you will see a % (percent-sign) character:

harley@kajsa:∼%

If you are logged in as superuser (see Section 2.3), no matter what shell you are using you will see a # (number sign) character:

harley@kajsa:∼#

A prompt that ends with # is telling you to be very careful: you are superuser and, if you make a mistake, you could cause a lot of damage.

The first shell prompt I showed you is the default Ubuntu Linux prompt. Let’s take a moment to dissect it:

harley@kajsa:∼$

First, you see the name of my userid (harley). Then you see the @ (at sign) character, followed by the name of my computer (kajsa), and a : (colon). Following the colon is a ∼ (tilde) character. (It has a special meaning that I will get to in a moment.) Next, you see a $ (dollar sign) character. This indicates that your shell is a member of the Bourne Shell family (in this case, Bash). Finally, at the very end of the prompt is a space, which you can’t see.

So what is the meaning of the ∼ (tilde) character? It is actually the pathname of your "current directory". (We will discuss this in Section 2.17.)

At any time, you can think of yourself as working within a directory. For now, I’ll just tell you that the tilde stands for your personal "home directory". As you move from one directory to another, this part of the prompt will change to show where you are. For example, let’s say that I changed from my home directory to the Documentssubdirectory. The shell prompt would become:

harley@kajsa:∼/Documents$

And let’s say that this directory had a subdirectory of its own called archive. If I change to that subdirectory, the shell prompt would become:

harley@kajsa:∼/Documents/archive$

Finally, if I changed to the /usr/include/protocols directory, the prompt would change to:

harley@kajsa:/usr/include/protocols$

To review, the general format of the default Bash shell prompt with Ubuntu Linux is:

userid              @              computer:current-directory              $            

2.9 Section 2.9: What Unix Commands Look Like

Whenever you see the shell prompt, you can enter commands one at a time. When you are finished typing a command, you tell the shell to process it by pressing the Enter key (or the Return key on a Macintosh keyboard). As an example, here’s the command that you would use to start Emacs (once it is installed) to edit a file named important:

emacs important

As a general rule, most Unix commands have the following format:

command-name short-options long-options parameters                

In the example above, the command name is emacs; there are no short options or long options, and there is one parameter, important.

Short options start with a single – (hyphen) character. Long options start with two hyphen characters in a row. Let us analyze the following example using the ls command lists (used to display information about files).

ls -l --classify Documents Music

The command name is ls. There is one short option (-l), one long option (--classify), and two parameters (Documents and Music).

If a command has more than one short option, you can put them together with a single hyphen. For example, let’s say you want to use the ls command with three short options (-a -l -d). The following commands are equivalent:

ls -ald
ls -a -l -d

When we talk about such commands out loud, there are two conventions we follow. First, for short, two-letter commands, we pronounce the separate letters. For example, when we talk about the ls command, we call it the "L S" ("ell-ess") command; and the name of the vi text editor is pronounced "V I" ("vee-eye").

Second, when we talk about options, we pronounce the - (hyphen) character as either "minus" or "dash". For example, let’s say you wanted to tell someone to use the following command:

ls -l

You would say "Use the L S minus L command" or "Use the L S dash L command".

2.10 Section 2.10: Making Corrections as You Type Commands

As you type a Unix command, there are keys you can use to modify the command or to make corrections. The most important is the Backspace key . As you type, whenever you make a mistake, just press <Backspace> as many times as necessary and fix the mistake.

You can also make changes by using the two arrow keys , <Left> and <Right>, to move the cursor within the command. You can then use <Backspace> to delete the character to the left of the cursor, or <Delete> to delete the character at the cursor.

If you are used to a PC keyboard you probably already know how to use these keys. However, Unix also uses two other keys you may not know about. To delete the previous word, press <Ctrl-W>. To delete the entire line, press <Ctrl-U> (on some systems, <Ctrl-X>). For a summary of these keys, see Figure 2-7.

Figure 2-7. Keys to Make Corrections When Typing a Command. As you enter a command, here are the most important keys you can use to make corrections. These keys work with all Unix systems, including Mac OS X. The first four keys also work when you type commands with Microsoft Windows. However, <Ctrl-W> and <Ctrl-U> do not work with Windows, as they are Unix keys.

2.11 Section 2.11: Two Important Keys: <Ctrl-C> and <Ctrl-D>

To enter a command, you type it and then press the Enter key. When you press <Enter>, you are telling the shell to process the command.

A small number of commands are built in to the shell. When you enter such a command, the shell handles it on its own. Most commands, however, require the shell to run another program on your behalf. For example, if you enter the date command (to display the time and date), the shell will start a program named date. The shell then places itself on hold, waiting for the program to finish. The moment the program finishes, the shell regains control. It then displays the shell prompt and waits for you to enter another command.

The same thing happens when you enter the emacs command. The shell starts Emacs and then puts itself on hold. When you quit Emacs, the shell regains control and displays the shell prompt.

From time to time you may want to quit (stop) a program that is running. How you do so depends on which user interface the program uses.

Programs that use a TUI (text-based user interface) take over the screen and create their own environment. Such programs will have a quit command that you use to end the program. For example, when you run Emacs, it will keep control until you stop it deliberately. (The most common way to do this is by pressing <Ctrl-X> <Ctrl-C>.) Here is another example. In Section 2.11, I will show you how to access the Unix manual. If you are displaying information from the Unix manual and you want to stop, you use the q (quit) command.

Programs that use a CLI (command-line interface) are different. They don’t take control of the screen. Instead, they write each line of output to the bottom of the screen, causing all the other lines to scroll up.

With many commands, the output is short and the command finishes quickly. This is the case, for example, when you enter the date command. Within an instant, the shell runs the date program, the time and date are displayed, the program ends, and you see the next shell prompt.

Some CLI programs, however, may not stop on their own, either by design or if they run into a problem. When this happens, you will have to interrupt the program to get it to stop. You do so by sending it a SIGNAL, a special notification that is sent to a program that is running. Specifically, to stop a program, you press <Ctrl-C> to send the program an intr signal (INTERRUPT SIGNAL). Most CLI programs will stop instantly when they detect an intr signal.

If you want to try this, enter the following command:

ping www.harley.com

The ping command sends a PING SIGNAL to another computer to see if it responds, and then displays technical information about the response (or lack of response). If you use ping without any options, it will keep sending the signal and displaying output indefinitely. To stop ping, simply send an intr signal by pressing <Ctrl-C>.

Some CLI programs invite you to enter data for the program to process, and as long as you keep entering data the program will keep running. An interesting example is the factor program. Once you start factor, it waits for you to enter a whole number. It then breaks the number down into prime factors, which it displays. For example, if you enter the number 68, factor will calculate that 68 = 2 x 2 x 17, and respond with:

68: 2 2 17

At this point, the program waits for you to enter another number. On its own, factor will never stop. To stop such programs, you must indicate that there is no more data. To do so, you press <Ctrl-D> to send an eof signal (END OF FILE SIGNAL).

If you want to try this, enter the command:

factor

Then enter any whole number you want followed by <Enter>, over and over, as long as you want. When you want to stop, press <Ctrl-D>.

As we have discussed, when you use the shell, you enter one command after another. The shell processes each command appropriately and then waits for you to enter another one. Because the shell is a CLI program, you can press <Ctrl D> to indicate that there is no more data. When you do this, the shell, like all CLI programs, will stop. The moment the shell stops, your userid is logged out automatically.

Thus, when you are using a terminal, whenever you see a shell prompt, you can log out by pressing <Ctrl-D>. (You can also enter the logout command.)

2.12 Section 2.12: The History List ; Command Line Editing

As you use the command line, the shell maintains a list of the commands you enter. This list is called the HISTORY LIST. At any time, you can recall commands from the history list, which you can then modify and reuse.

For example, let’s say you want to use the ls -l command to display information about the files in the directory named /usr/include/protocols. The command you want is:

ls -l /usr/include/protocols

However, by accident, you enter:

ls -l /usr/include/protcols

This won’t work because you forgot to type the second "o" in protocols.

Instead of typing the entire command again (and probably making another mistake), you can recall what you just typed from the history list. It will then be the work of a moment to fix the mistake and re-enter the corrected command. (I’ll show you how in a moment.)

You can do a lot with the history list and the details are complex. However, because it is worth learning, I will describe a few of the basic techniques. Afterwards, I will explain how this is all connected with Emacs.

Think of the history list as an invisible file containing your most recent Unix commands. Each time you enter a new command, it is inserted into the bottom of the history list. So the last line of the invisible file is always the last command you entered.

The simplest way to move up and down through the invisible file is to use the <Up> and <Down> (arrow) keys. As you do, the shell displays the command to which you are pointing within the invisible file. When you press <Up>, the current command vanishes and is replaced by the previous command, as if you were going back in time. If you go too far, you can press <Down> to move back down the list.

Once you display a command from the history list, you can modify it however you want. You then press <Enter> to tell the shell to process the newly modified command. Let’s consider our example.

To start, let’s say you enter the following, incorrect ls command:

ls -l /usr/include/protcols

Because you made a spelling mistake, you see the following error message:

ls: cannot access /usr/include/protcols: No such file or directory

To recall the incorrect command from the history list, press the <Up> arrow once. You now see, once again, the incorrect command:

ls -l /usr/include/protcols

To fix it, press <Left> four times to move the cursor between the t and the c in protcols. Then press o to insert the letter "o". You now see:

ls -l /usr/include/protocols

To enter the corrected command, press <Enter>.

As I said, there is a lot you can do with the history list and it is all worth learning. However, it will take you some time to learn. At the very least, however, here are the basic ideas I want you to remember:

1. The history list is an invisible file containing your recently entered Unix commands.

2. To move up and down through the list, use the Up key and the Down key. As you move through the history list, the shell will show you the appropriate command.

3. To move the cursor within a command, use <Left> and <Right>.

4. As you make corrections and changes, you delete characters by using <Backspace>, <Delete>, <Ctrl-W>, and <Ctrl-U> (or <Ctrl-X>). For a summary of these keys, see Figure 2-8.

   

   Figure 2-8. Key Combinations to Use When Typing a Command. The top list shows the keys we discussed in Section 2.10 that you can use to make corrections when you are typing a command. The bottom list shows some of the key combinations copied from Emacs as part of the GNU Readline facility. You can use the keys in both these lists to move within the current line and the history list, and to help you make changes.

The shell has a powerful, built-in facility called COMMAND LINE EDITING. In fact, it is command line editing that enables you to modify commands as you type, to access the history list, and to use autocompletion (which we won’t go into here).

You will recall that, in the last few sections, I showed you how to enter commands and make corrections as you were typing. I then explained how to move within the history list, recall a previous command, modify it, and enter it again. What I was showing you was actually basic command line editing. What you didn’t realize is that I was also showing you basic Emacs editing commands. (So if you were following along on your own computer, you were actually using a few Emacs keys.)

This is not as strange as you might think. The Emacs editing commands are so powerful and (once you master them) so easy to use, that many other programs also use them. In particular, the most popular shells (Bash, tcsh, Korn Shell) all recognize Emacs key combinations that you can use for command line editing, that is, for moving through the history list and modifying commands, and for autocompletion. These capabilities are provided by a software library called GNU Readline. For reference, some of these Emacs key combinations are shown in Figure 2-8.

This means that, as you learn the Emacs key combinations, you can immediately use them with the shell for command line editing: just another reason why, the more you learn Emacs, the closer you are to becoming a totally fulfilled and actualized human being.

However, none of this is a substitute for the real thing, so let’s move on. We still have more to cover before we can actually start using Emacs.

2.13 Section 2.13: The Unix Manual

All Unix commands and programs are documented in the UNIX MANUAL, a part of every Unix system. When a Unix person talks about THE MANUAL, they always mean the Unix manual. For example, if you ask your grandmother how to use the ls command, she might tell you, "Look it up in the manual, and let me know if you have any questions."

The Unix manual is considered to be authoritative, the definitive reference when it comes to basic information about a particular command or program. As such, when a programmer changes a program — say, to add a new option — he or she is expected to update the entry for that program in the manual.

Each entry in the Unix manual is called a MAN PAGE . Don’t take this term literally, though: most man pages are much longer than the size of a printed page. (Here is an extreme example: if you printed the Bash man page, a particularly long one, it would take 155 printed pages.)

To display a man page, you use the man command. Type man followed by the name of the command or program you want to learn about. For example, to read the man page for the ls command, enter:

man ls

To learn about the man command itself, use:

man man

To look up something on the Bash shell man page, use:

man bash

Note: The Unix manual is a reference manual, not a teaching guide. At a minimum, each page shows you:

• Name of the command

• Description (usually only a few words)

• Syntax summary

• Options (description of all the options)

The SYNTAX of a command is the formal description of all the different ways you can enter the command and its options.

2.14 Section 2.14: Using the less Pager Program

When you use a terminal to display man pages, you are working in a text-based environment using a CLI (command line interface). As such, the man command writes its output to the bottom line of the terminal screen, causing previous output to scroll up. This works fine if the man page is short enough to fit on your screen. However, most man pages are much too long. Without a tool to display the output in a controlled fashion, most of the text would scroll off the top of the screen so quickly, you wouldn’t be able to read it.

To make the output readable, the man command does not write it directly to the screen. Instead, it sends it to a special tool called a PAGER PROGRAM or, more simply, a PAGER. The job of a pager is to take all the output and display it one screenful at a time. This lets you read the output in a controlled fashion. In fact, you can use the pager to move backwards and forwards, to search for a particular string of characters, to jump to the beginning or the end of the page, and much more.

The default Unix pager is called less.

-- More --

When less is running, it controls the entire screen. It starts by displaying the first screenful of output, with an informative message on the bottom line of the screen (the command line). It then waits for you to enter a command, of which there are many.

As I said, less has many commands that you can use while you are reading text. If you want to see them all, look at the less man page:

man less

(As you do, you will be using less to read about less.)

For reference, Figure 2-9 shows the basic less commands. The three most important ones are:

• Press the <Space> bar to display the next screenful of text

• Press the q key to quit the program

• Press the h key to display help information

Figure 2-9. Commands to use with less. The default Unix pager program is named less. The purpose of less is to display text, one screenful at a time. While you are reading, there are many commands you can use. Hereare the most important ones.

Notice that you can navigate by using either single-letter commands, or by using the special keys <Home>, <End>, <PageDown>, and <PageUp>.

When you have a moment, enter the man command above and spend some time practicing with less. This is a program that you need to learn how to use, because it is the key that unlocks the Unix manual.

2.15 Section 2.15: The Three Types of Unix Files

As we discussed in Section 1.2, the primary use of Emacs is to create and modify text files: programs and scripts, data files, HMTL files, LaTeX documents, logs, and so on. For this reason, it is important to understand how files are organized. Specifically, I want to make sure you are familiar with the idea of a hierarchical filesystem, as well as the basic concepts that support it: files, directories, and subdirectories. I also want you to know the names of the Unix commands we use to work with files and directories.

Being able to manage your files is a basic skill you need if you are to use Emacs well. To do so, there are two sets of tools, and I want you to be skillful with both of them. First, you can use the standard Unix file and directory commands that everyone learns. Second, you can use a TUI-based file management program called Dired (Directory Editor) that is part of Emacs. (We will talk about Dired in Section 12.6.) In either case, you will need to know the basic concepts, so let’s start with files.

There are three types of Unix files: ordinary files, directories, and pseudo files. An ORDINARY FILE is what most people think of when they use the word "file": a collection of data that has a name and is stored on a disk or other storage device. With Emacs, we generally work with text files, ordinary files that contain the characters you can type on a keyboard: letters, numbers, punctuation, spaces and tabs.

A DIRECTORY is used to organize groups of files. For instance, you might create a directory named circus to hold a collection of photos from a trip to Centerboro, New York, where you saw Boomschmidt’s Stupendous and Unexcelled Circus.²⁷ When we talk about a directory, we say that it CONTAINS or HOLDS other files. Literally, this is not the case. Directories contain information about files, not the actual files themselves.

The reason directories are so important is that they can contain other directories, as well as ordinary files. This allows you to create a hierarchy of directories to organize your data. When a directory contains another directory, with respect to one another we call the first one the PARENT DIRECTORY and the second one a SUBDIRECTORY.

For example, if you have a lot of photos in your circus directory, you might organize them by using three subdirectories: animals, friends and martians. In this case, circus is the parent directory of animals, and animals is a subdirectory of circus.

Traditionally, the term "directory" is used by people who are comfortable working with a command-line interface. People who use a GUI (graphical user interface) tend to refer to directories as FOLDERS and subdirectories as SUBFOLDERS.

A moment ago, I told you that when most people think about a file, they consider it to be "a collection of data that has a name and is stored on a disk or other storage device". This description is certainly accurate for both ordinary files and directories. As a definition, it is intuitive and for some systems, such as Microsoft Windows , it works just fine. With Unix, however, the concept of a file is much more generalized. Specifically, a Unix FILE is any source from which data can be read, or any target to which data can be written.

There are different types of Unix files, but they all fall into one of three categories: ordinary files, directories, or pseudo files . Unlike ordinary files and directories, PSEUDO FILES do not store data. Instead, they provide services to programs using the same methods that are normally used to read and write data from ordinary files. As such, pseudo files are part of the Unix filesystem and, like ordinary files, they are organized into directories. The three most important types of pseudo files are special files, named pipes, and proc files.

SPECIAL FILES (also called DEVICE FILES) represent physical or emulated devices. NAMED PIPES connect the output of one program to the input of another. PROC FILES provide technical information about the system itself.

Although we don’t need to get into a lot of details, it is important that you understand the general concept: pseudo files do not store data in the regular manner, but they can be used for input and output in the same way as you would use an ordinary file.²⁸

2.16 Section 2.16: The Tree-Structured Filesystem

Most people run Emacs on some type of Unix system, such as Linux, FreeBSD, NetBSD, or OpenBSD. However, you can also use Emacs with Mac OS X (which is actually Unix) and Microsoft Windows (which is most definitely not Unix). There are some differences between how filesystems work with Linux and BSD compared to OS X and Windows, and we will talk about them in Section 2.17. What’s most important, however, is that all of these operating systems organize files into a hierarchy, a basic paradigm I want to make sure you understand.

A typical Unix system contains well over 300,000 files. (I am not exaggerating.²⁹) These files are organized into a TREE-STRUCTURED FILESYSTEM in which one main directory, called the ROOT DIRECTORY, serves as the parent directory for the entire filesystem. The root directory is — directly or indirectly — the parent of all the other directories in the system. (Think of a tree where the trunk is the root directory, and all the branches are subdirectories.)

When we write the name of the root directory, we don’t use the name "root". Instead, we simply write a single / (slash) character. Here is an example using the ls (list) command, which is used to display information about a directory. The following command displays the names of the files in the root directory:

ls /                

The basic way to write the name of a directory is to simply trace the path from the root directory, through every subdirectory that leads to the target directory. Within the sequence of directories, we use / characters as delimiters, to separate one directory name from another. Here is an example.

Let’s say the root directory contains a subdirectory named home, which contains a subdirectory named harley, which contains a subdirectory named circus, which contains a subdirectory named animals. We would write the full name of the animals directory as follows:

/home/harley/circus/animals

To display the contents of this directory, we can use the following ls command:

ls /home/harley/circus/animals

If we want to reference the name of an ordinary file, we simply put another / at the end of the last directory and add the file name onto the end of the list. For example, let’s say there is a file called leo.jpg in the animals directory. We can reference it as follows:

/home/harley/circus/animals/leo.jpg

When we use this pattern to specify a sequence of directories (possibly with a file at the end) separated by / characters, we call it a PATHNAME or, more simply, a PATH. If a pathname ends with a file, we call that part of the path a FILENAME. For instance, the example above is a pathname. The last part, leo.jpg, is a filename.

You will have noticed that our example used the directory home, which is a subdirectory of the root directory. Each time a userid is created, the system creates a HOME DIRECTORY for the person using that userid to store his or her personal files. Each userid’s home directory is a subdirectory of /home, and its name is the same as the userid. For example, let’s say that a system is used by four different people whose userids are harley, lydia, jeff and dmitry. Their home directories will be:

/home/harley
/home/lydia
/home/jeff
/home/dmitry

Each of these people can create their own subdirectories within their home directory. In this way, every Unix user is able to design a personal directory tree to organize his files in a way that make sense to him or her. As an example, let’s say that, within the /home/harley directory, there is a circus subdirectory, and within that, three subdirectories named animals, friends and martians. We have the following personalized directory tree:

/home/harley
/home/harley/circus
/home/harley/circus/animals
/home/harley/circus/friends
/home/harley/circus/martians

The /home directory is only one of many built-in subdirectories of the root directory. There are also /bin, /dev, /etc and more. It is these "first-level" subdirectories that define the shape and function of the Unix filesystem. Many (but not all) of these subdirectories are the same from one Unix system to another. Once you get used to the basic plan, it will be generally the same no matter what system you use to run Emacs as long as it is Unix: including Linux, any BSD system, or Mac OS X. (Microsoft Windows, however, is different in that it uses a completely separate file system for each storage device.)

man hier

Although there is no universal master plan that all Unix systems are required to follow, there is a widely recognized plan called the FILESYSTEM HIERARCHY STANDARD, or FHS, that is used with most Linux systems. (In fact, the FHS is maintained by the Linux Foundation.) For reference, Figure 2-10 shows the most important directories within the Filesystem Hierarchy Standard, Version 3.0.

Figure 2-10. The Most Important Directories Within the Filesystem Hierarchy Standard. All Unix systems organize files and directories into a tree-structured filesystem using a singleroot directory. The Filesystem Hierarchy Standard is the basic plan followed by Linux systems. To see the details for your particular system, look at the hier man page.

2.17 Section 2.17: The Current Directory and Pathnames

At all times, one specific directory is designated as your CURRENT DIRECTORY, also called your WORKING DIRECTORY . Informally, this is the directory in which you are working at that moment. When you log in, your current directory is set to your home directory. For example, my userid is harley, so when I log in, my current directory is set to /home/harley.

In Section 2.16, we discussed how to specify pathnames. Starting from the root directory (/), you specify each subdirectory (or filename) using / characters as delimiters. For example:

/home/harley/circus/animals/leo.jpg

A pathname that begins with a / character starts from the root directory. This is called an ABSOLUTE PATHNAME . If the pathname doesn’t begin with a /, the pathname starts from your current directory. This is called a RELATIVE PATHNAME. Here is an example.

Let’s say that, at this moment, your current directory is /home/harley. The following two paths are equivalent:

/home/harley/circus/animals/leo.jpg
circus/animals/leo.jpg

Because the second pathname does not begin with a /, it starts from your current directory, which is /home/harley.

The concept of a current directory is important because it means that you rarely have to type long, absolute pathnames. Once you set your current directory to wherever you want to work, you can use shorter pathnames relative to that directory (as I did in the last example).

For convenience, there are three standard abbreviations you can use when you type pathnames. First, the tilde (∼) character is a synonym for your home directory. For example, if your home directory is /home/harley, typing ∼ at the beginning of a pathname is the same as typing /home/harley. Thus, the following two ls commands would be equivalent. (The command ls -l displays information about a file.)

ls -l /home/harley/circus/animals/leo.jpg
ls -l ∼/circus/animals/leo.jpg

The other two abbreviations are . (a single period) and .. (two periods in a row), pronounced "dot " and "dot-dot" respectively. The . abbreviation stands for your current directory. For example, let’s say that your current directory is:

/home/harley/circus/animals

The following two commands both refer to the file leo.jpgin this directory:

ls -l leo.jpg
ls -l ./leo.jpg

You might ask, why would you want to type a . character at the beginning of a pathname? Normally, you wouldn’t because it’s not necessary. However, there are times you do need to use it. For example, if you want to run a program from your current directory, and that directory is not in your search path, you must use ./ to specify the path explicitly. (If you don’t understand what I just said, you can ignore it.)

The final abbreviation .. stands for the parent directory. You use it when you want to go "up" one level within a pathname. For example, let’s say that the circus directory has three subdirectories: animals, friends and martians. The martian directory contains a file named chirp-squeak.jpg. You want to display information about the file chirp-squeak.jpg in the martians directory, and your current directory is:

/home/harley/circus/animals

The following two commands are equivalent:

ls -l /home/harley/circus/martians/chirp-squeak.jpg
ls -l ../martians/chirp-squeak.jpg

The first command uses an absolute pathname that starts from the root directory. The second command uses a relative pathname that starts from the current directory (animals), goes up one level (to circus), and then goes down one level (into martians).

At this point, you may be wondering, at any moment, how do you know what directory is your current directory? There are two ways.

First, you can use the pwd command . The name stands for "print working directory":

pwd

Remember this command: if you ever get lost, pwd will tell you where you are.

The second way to find out the name of your current directory is to look at your shell prompt. As we discussed in Section 2.8, it is likely that, by default, your shell prompt will display the name of your current directory. For example, the default Ubuntu Linux shell prompt is:

userid                  @                  computer:current-directory                  $                

This means that, unless you have changed your shell prompt, it will always show you where you are in the directory tree.

Here are some examples using the cd command , which is used to change your current directory. (All you do is specify the directory to which you want to change.)

cd
cd ∼

In the following examples, I will include the shell prompt so you can see how the current directory is changing. Before we start, I will tell you that my userid is harley and my computer is named kajsa. ³⁰

The examples start just after I log in, at which time my current directory is set to /home/harley. I then use cd to move from one directory to another. Take your time to read the examples slowly, and make sure you understand exactly what is happening. As you read, remember that ∼ stands for the home directory, and .. refers to the parent directory.

harley@kajsa:∼$ cd circus
harley@kajsa:∼/circus$ cd animals
harley@kajsa:∼/circus/animals$ cd ../martians
harley@kajsa:∼/circus/martians$ cd ∼
harley@kajsa:∼$ cd /usr/share/man/man1
harley@kajsa:/usr/share/man/man1$ cd ..
harley@kajsa:/usr/share/man$ cd ..
harley@kajsa:/usr/share$ cd ..
harley@kajsa:/usr$ cd ..
harley@kajsa:/$ cd ..
harley@kajsa:/$ cd
harley@kajsa:∼$ cd circus/martians
harley@kajsa:∼/circus/martians$ cd ../..
harley@kajsa:∼$

Notice that you can use more than one .. in a row to go up more than one level at a time (second line from the bottom). Notice also that when you try to go up from the root directory nothing happens (fifth line from the bottom).

To finish this section, I have created two reference lists to show you the most important file and directory commands. Figure 2-11 shows the most important commands to use with ordinary files. Figure 2-12 shows the most important directory commands.

Figure 2-11. The most important file commands. When you use Emacsthere will be many times when you need to manipulate your files. Sometimes you can do it from within Emacs, but a lot of the time, it will be easier and faster to use the standard Unix file commands. These are the most important ones, and I recommend you learn how to use them all. (Notice that cat, mv, and touch each perform two different functions.)

Figure 2-12. The most important directory commands. Unix uses a very large, tree-structured file system. Within that file system, starting from your home directory, you can build a tree structure of your own in a way that suits you. This will become more and more important, as you develop a facility with Emacs. Here are the commands you can use to build, maintain, and use your own personal directory tree. (Notice that mv performs two different functions.)

Why do I list all these commands? Emacs is linked tightly to Unix and to the Unix command line, and understanding how to use files and directories is a basic skill you need to know. If you talk to anyone who is a skilled Emacs user, it is likely that he or she will know how to use all the commands I have listed in these two tables.

2.18 Section 2.18: File and Directory Names

To complete our discussion about Unix and its file system, I want to spend a few minutes talking about how to name files, specifically, ordinary files and directories. There are small differences with Mac OS X, and larger differences with Microsoft Windows, which we will talk about in Section 2.19.

Before we start, I want to take a moment to remind you that the topics we have covered in this chapter give you the basic knowledge about Unix you need to use Emacs. However, there is a lot more to learn about Unix, and it will take time and experience for you to do so. If you want a more comprehensive Unix reference, please get a copy of my book Harley Hahn’s Guide to Unix and Linux.³¹ This is a book you will want to keep as a permanent reference, so I recommend you look for an actual printed book, not an electronic copy.

Now, to continue. There are four important ideas you need to remember about naming files and directories.

photos from the circus

ls -l 'photos from the circus'

harley Harley HARLEY haRLey

2.18.4 4. DOTFILES

There are many files that, for one reason or another, you will want to ignore most of the time. For example, some programs will put a configuration file in one of your directories. The program will use this file silently, which is fine, but you don’t want to look at it every time you display the contents of the directory.

By default, the ls command will not display the names of files whose names begin with a . (dot) character. Such files are called DOTFILES or HIDDEN FILES. If you want to see dotfiles, you use ls with the -a (all) option. This means that, if you have a lot of configuration files (which are normally dotfiles), you don’t have to look at them unless you really want to.

As an experiment, try this. Use cd to make sure you are in your home directory. Then use ls to display all the files and directories that are not dotfiles. Then use ls -a to display all your files, including dotfiles, and notice how many there are.

cd
ls
ls -a

If you use Bash for your shell, you will see several dotfiles that are the Bash configuration files. For reference, I have listed them in Figure 2-13. I’m showing these to you for two reasons. First, they are a good example of how dotfiles are used. Second, you may want to use Emacs to edit one or more of these files to customize your command line environment. If so, start by looking in the files to see what is already there, figure out what you want, and make your changes carefully.

Figure 2-13. Bash Configuration Files. Many programs use dotfiles to hold configuration information. These are the files used by Bash, the default shell on many Unix systems (including most types of Linux as well as Mac OS X). Once you learn how to use Emacs, I suggest that you take some time to learn about these files and customize them.

Note

When you are using the command line, you see dotfiles by using the ls -a command.

With a GUI-based file manager, if you want to see dotfiles, you will have to turn on a specific option. For example, with Nautilus (the file manager used with Ubuntu Linux),³² if you want to see dotfiles, you need to pull down the View menu and select "Show hidden Files". (The shortcut key is <Ctrl-H>.)

2.19 Section 2.19: File and Directory Names: OS X and Windows

What we have discussed in Section 2.18 applies to virtually all types of Unix. To finish our discussion, I’d like to take a moment to tell you the differences you will find with Mac OS X and with Windows.

ls harley
LS HARLEY
Ls Harley
lS harLEY

ls -a harley
ls -A harley

cd 'New Programs'

dir "Saved Games"