Harley Hahn's Guide to Unix and Linux

As you know, the shell is the program that reads and interprets your commands. From the very beginning, the shell was designed to be a regular program, one that requires no special privileges to do its job. In this sense, it is like any other program that might run on a Unix system.

Because of this basic design, it is possible for anyone with the requisite programming skill to design his own shell, which he can then share with other Unix users. Over the years, this is exactly what has happened and, today, there are a large number of shells in use. Your Unix system will have at least a few, and you can use whichever one you want. You can even switch back and forth from one shell to another. If you want to try a shell that is not installed on your system, there are a variety of shells you can download from the Internet for free.

In this chapter, I will answer several questions: What is the shell, and why is it important? What are the most popular shells? Which shell should you use? In the following chapters, I will teach you how to use the most important shells: Bash, the Korn Shell, the C-Shell, and the Tcsh.

Once you start using Unix, you will hear a lot of talk about the shell. Just what is this "shell" thing, anyway? There are several answers.

The short technical answer is that a SHELL is a program that acts as a user interface and script interpreter, allowing you to enter commands and, indirectly, to access the services of the kernel.

To be a bit less technical, let me give you a more elaborate, two-part description of a shell. First, a shell is a COMMAND PROCESSOR: a program that reads and interprets the commands that you enter. Every time you type a Unix command, the shell reads it and figures out what to do. Most shells also offer facilities to make your minute-to-minute work more convenient. For instance, you can recall, edit and re-enter previous commands.

In addition to being a command interpreter, a shell also supports some type of programming language. Using this language, you can write programs, called SHELL SCRIPTS, for the shell to interpret. These scripts can contain regular Unix commands, as well as special shell programming commands. Each type of shell has its own specific programming language and rules. As a general rule, however, shells within the same "family" use similar programming languages. (We will talk about the two main families of shells later in the chapter.)

Just between you and me, none of these explanations really captures the je ne sais quoi — that certain something — that surrounds the idea of the shell. You see, the shell is your main interface into Unix. Since there are a variety of shells, you have a choice as to which interface you use and, your choice affects how Unix feels to you as you use it.

As you can imagine, there are all kinds of arguments among the cognoscenti as to which shells are best and which shells should be avoided at all costs. Until you are an experienced Unix user, however, it doesn't really matter which shell you use. The differences, though important, are not significant to beginners: you might as well use whichever shell is the default on your system. Once you get more experience, you can choose the shell you like the best and then use it to create a highly customized work environment for yourself.

At that point — once you know how to deliberately manipulate your work environment — you will begin to understand the mysterious feeling people have for the shell. You can't see it and you can't touch it, but it is always there, waiting to serve your every need in the way that works best with your individual thinking process. (If you are a pantheist, this will make perfect sense.)

What's in a Name?

Shell

There are three ways to think about the name "shell". First, a Unix shell provides a well-defined interface to protect the internals of the operating system. In this sense, a shell acts like the shell of an oyster, shielding its vulnerable parts from the harsh realities of the outside world.

Alternatively, you can visualize a seashell that winds around and around in a spiral. When you use a Unix shell, you can pause what you are doing and start another shell or another program whenever you want. Thus, you can put as many programs as you want on hold, each one "inside" its predecessor, just like the layers of a real seashell.

My advice, however, is to refrain from asking the question, What does the name "'shell" mean? Instead, think of the word "shell" as a brand new technical term (like RTFM or foo), and let its meaning come solely from your experience with Unix over the years.

The shell is a program and, like all programs, it is known by the name of the command you type to run it. The very first shell was written in 1971 by one of the original creators of Unix, Ken Thompson, two years after Unix was invented. (See Chapter 2 for the history of Unix.) In keeping with the tradition of giving programs short names, Thompson named the shell sh.

Let's pretend that you are an early user in the early 1970s. Here is how you would use the sh program. To start, you log into the system by typing your userid and password (see Chapter 4). Once your password is validated and the various startup procedures have been carried out, Unix runs the sh program on your behalf, which begins your work session.

The sh program displays a shell prompt (see Chapter 4) and waits for input. Each time you enter a command, sh does whatever is necessary to process it; once the command is finished, sh displays a new shell prompt and waits for another command. Eventually, you tell sh there is no more input data by pressing ^D to send the eof [end of file] signal (see Chapter 7). Upon trapping this signal (again, see Chapter 7), sh terminates and you are logged out, ending your work session.

Today, using the shell is basically the same experience as it was in 1971. To be sure, modern shells are a lot more powerful than the original sh program, but they still act as your interface by reading one command after another and terminating when there is no more data. (This is why the shell is called the CLI, command line interface.)

The very first shell, which we might call the Thompson shell, was used from 1971 to 1975, being distributed with Unix First Edition (Version 1) through Unix Sixth Edition (Version 6). In 1975, a new shell was written by a group of Bell Labs programmers led by John Mashey. This new shell was released in 1976 as part of a special version of Unix called the Programmer's Workbench or PWB. Because the Mashey Shell (also called the PWB Shell) was designed to replace the original shell, it was also named sh.

The advantage of keeping the same name for a new shell is that, as a user, you don't have to do anything special when the new shell is introduced. One day, you run the sh program and you get the old shell; the next day, you run the sh program and you get the new shell. As long as the new shell is compatible with the old shell, everything works fine. You can do everything you did in the old shell and, if you want, you can take advantage of the enhanced features of the new shell.

When a new program relates to an old program in this way, we say that the new program is BACKWARDS COMPATIBLE with the old program. For example, the Mashey Shell was backwards compatible with the original Thompson Shell.

Because the shell was designed to be a regular program, anyone who had enough expertise could change an existing shell to their liking, or even write their own shell(*). In 1976, another Bell Labs programmer, Steve Bourne, started work on a brand new shell. Because it was designed to replace the older Thompson shell, the BOURNE SHELL was also named sh.

Both the Mashey and Bourne shells offered important improvements, particularly in the area of programming and, within a short time, both shells had gained a significant following within Bell Labs. However, although they were both backwards compatible with the existing sh program, they were incompatible with one another. This led to an internal debate as to which shell should become the standard Unix shell. The result of this debate was important, for it changed the course of Unix for years to come.

At three successive Unix user meetings, Mashey and Bourne each discussed their shells. In between the meetings, they both worked hard to enhance their shells by adding new functionality. To settle the problem once and for all, a committee was formed to study the issue; they chose the Bourne shell.

Thus, with the release of Unix Seventh Edition (Version 7), the Bourne shell became the default shell for all Unix users. In fact, the Bourne shell was so stable and so well-designed that, for many years, it was the standard Unix shell. From time to time, new versions of the shell were released and, each time, the shell kept its backwards compatibility and the name sh. The Bourne shell became so widely used that, today, all compatible shells — older and newer — are considered to be members of the BOURNE SHELL FAMILY.

In 1982, another Bell Labs scientist, David Korn, created a replacement for the Bourne shell, called the KORN SHELL or ksh. The new shell was based on tools that Korn and other researchers had been building over the last several years. As such, it represented a vast improvement over the standard Bourne shell. In particular, the new Korn shell offered a history file, command editing, aliasing, and job control (all of which we will discuss later in the book).

Korn ensured that the ksh program was backwards compatible with the current sh program, and within a short time, the Korn shell became the de facto standard within Bell Labs. With the next release of Unix, the Korn shell was distributed to the world at large, and it soon became a permanent replacement for the Bourne shell. Since then, there have been two new major releases of the Korn shell:, Ksh88 in 1988, and Ksh93 in 1993.

In the early 1990s, a great deal of pressure grew to standardize Unix (see Chapter 2). This pressure led to two different movements, one controlled by organizations and committees, the other arising from popular demand. Each movement had its own solution to the question: How can we standardize the Unix shell once and for all?

The "official" movement created a large set of specifications called POSIX (pronounced "pause-ix"), a blueprint for standardizing operating systems. For practical purposes, you can think of POSIX as an organized attempt by commercial interests to standardize Unix.

What's in a Name?

POSIX

The project to standardize Unix was initiated under the mantle of an organization called the IEEE. At first, the project was called IEEE-IX, but since this was such a bad name, the IEEE tried to come up with something better.

They had trouble doing so and, at the last minute, Richard Stallman, founder of the Free Software Foundation (see Chapter 2), suggested the name POSIX. Stallman chose the name as an acronym for "Portable Operating System Interface". The adventitious "X" was added to make the name look more Unix-like.

An important part of the POSIX standard was the specification for the basic features of a shell. Over the years, this standard has had several names including IEEE 1003.2 and ISO/IEC 9945-2(*). For companies, governments and other organizations, the 1003.2 standard was an important benchmark in that it gave anyone who worked on shell development a well-defined baseline target for which to aim. For example, the Ksh93 shell was designed to conform to the 1003.2 standard.

The 1003.2 standard, however, was not readily available to individuals. Indeed, it cost money to get a copy of the technical details(*). Among most Unix programmers, the prevailing ethic was not to follow one universal standard such as POSIX, but to create free software that could be modified and enhanced by anyone. As we discussed in Chapter 2, the free software movement led to the development of the Free Software Foundation and to the creation of Linux. The Korn shell, however, could not be distributed with Linux. The problem was that the Korn shell, being part of Unix, was a commercial product that belonged to AT&T. As such, it was not available to the general public.

In 2000, AT&T finally allowed the Korn shell to become an open source product, but it was too little too late. In the 1990s, a number of free, open source shells were created, the most important of which were the FreeBSD Shell, Pdksh, the Zsh, and Bash. All of these shells complied with the 1003.2 standard, making them adequate replacements for the Korn shell.

The FREEBSD SHELL, as the name implies, is the default shell for FreeBSD. In keeping with tradition, it is known as sh, the standard name for a member of the Bourne shell family. (In other words, if you are using FreeBSD and you run the sh program, you get the FreeBSD Shell.)

PDKSH is a modern clone of the Korn shell. Pdksh was written to provide a Korn shell without restrictive licensing terms; hence the name "public domain Korn shell". The best way to think of Pdksh is as a modern Korn shell that is free in both senses of the word (no cost + open source). The original Pdksh was written in 1987 by a programmer named Eric Gisin, who based his work on a public domain version of the Unix Seventh Edition Bourne shell written by Charles Forsyth(*). Over the years, many people contributed to Pdksh. Since the mid-1990s, however, the shell has stabilized and remained mostly unchanged. This is because (1) it works well, and (2) most people in the open source community are using Bash (see below). Still, many Linux systems do include Pdksh as one of the installed shells so, if it is available on your system, you may want to give it a try.

The next important member of the Bourne shell family is the Zsh, pronounced "zee-shell" (even in England and Canada, where the letter Z is normally pronounced "zed"). The name of the Zsh program is zsh.

The Zsh was developed by Paul Falstad in 1990, when he was an undergraduate at Princeton University. His philosophy was to "take everything interesting that I could get my hands on from every other shell". As he explained, "I wanted a shell that can do anything you want". The result is a shell that offers all of the important features of the other Unix shells, as well as new capabilities that are not widely available. For example, you can tell the Zsh to notify you when a particular userid has logged in.

So where does the name come from? When Falstad was working on the shell, there was a teaching assistant, Zhong Shao, whose Unix userid was zsh. Falstad figured that would be a good name for a shell, and appropriated it for his new creation.

Within a short time of being released, the Zsh developed a cult following around the world and became popular among programmers and advanced Unix users. Today, the Zsh status is much like that of Pdksh: it works, it's stable, and it's a great shell. However, since the mid-1990s, new development has slowed to a crawl.

Of all the members of the Bourne shell family, the most important, by far, is BASH. Bash was originally created by Brian Fox (1987) and later (starting in 1990) maintained by Chet Ramey, all under the auspices of the Free Software Foundation. Today, Bash is supported by a community of programmers around the world. The name of the actual program, as you might guess, is bash.

Bash extends the capabilities of the basic Bourne shell in a manner similar to the Korn shell. Bash is not only a command processor with a powerful scripting language, it supports command line editing, command history, a directory stack, command completion, filename completion, and a lot more (all of which will make sense to you eventually).

Bash is free software, distributed by the Free Software Foundation. It is the default shell for Linux, as well as Unix-based Macintoshes, and is available for use with Microsoft Windows (running under a Unix-like system called Cygwin). In fact, every important Unix system in the world either comes with Bash or has a version of Bash that can be downloaded for free from the Internet. For all these reasons, Bash is the most popular shell in history, being used by millions of people around the world.

What's in a Name?

Bash

The name Bash stands for "Bourne-again shell", a name that is an acronym and a pun. The idea is that — literally and spiritually — Bash is based on a resurrected ("born again") version of the standard Unix shell.

Notice that, although we talk about the Korn shell or the C-Shell or the Zsh, we never say the Bash Shell. We always say "Bash".

As I described above, the original Bourne shell was introduced in 1977. A year later, in 1978, Bill Joy, a graduate student at U.C. Berkeley developed a brand new shell, which he based on the Unix Sixth Edition sh program, the predecessor of the Bourne shell. However, Joy did more than copy the existing functionality: he added many important improvements, including aliases, command history, and job control. In addition, he completely revamped the programming facilities, changing the design of the scripting syntax so that it resembled the C programming language. For this reason, he called his new shell the C-SHELL, and he changed the name of the program from sh to csh.

During the late 1970s and throughout the 1980s, the C-Shell became very popular. You might wonder, why should this be the case when there were already other good shells? There were several reasons.

First, the C-Shell offered major improvements over the standard Unix shell. Second, the C-Shell was included as part of the BSD Unix distribution (see Chapter 2), which itself was very popular. Finally, the C-Shell was created by Bill Joy, one of the most important Unix programmers of all time. Joy's tools, such as the vi editor , were extremely well-designed and tended to be used by a lot of people. (For a discussion of Joy's contributions to Unix, see Chapter 2.)

For a long time, the C-Shell was the shell of choice for experienced Unix users, especially at universities and research organizations, where it was usually the default shell. I first used Unix in 1976, and the C-Shell is the shell I started with. To this day, it is still close to my heart.

There were, however, two important problems with the C-Shell. One was solvable; the other, unfortunately, was not, and it led to the C-Shell falling out of favor among experienced users.

First, because of BSD's licensing terms, the C-Shell could not be distributed and modified freely, which was a big issue for many programmers. For this reason, in the late 1970s, a programmer named Ken Greer from Carnegie-Mellon University, began work on a completely free version of the csh, which he called tcsh. In the early 1980s, the responsibility for the TCSH (pronounced "Tee sea-shell") was passed on to a small number of programmers led by Paul Placeway at Ohio State.

The Tcsh was wonderful. Not only was it free (it was distributed in the public domain), but it enhanced the C-Shell by offering a number of advanced features, such as filename completion and command line editing. The Tcsh was attractive to a great many users and, over time, a large group of volunteers formed to maintain and extend it.

However, there was a problem that could not be solved: both the C-Shell and the Tcsh were not as good for programming as the Bourne family shells. Although the C-like syntax was fine for writing C programs, it wasn't as suitable for writing shell scripts, especially when it came to I/O (input/output). Moreover, both the C-Shell and the Tcsh had a number of design flaws, too esoteric to mention, which bothered the type of programmers who care about esoterica.

By the 1990s, all the popular shells were available on all Unix systems, and a general debate arose as to which shell was the best. Like a young lady whose dress was a bit too meretricious for her own good, the C-Shell began to lose its reputation without knowing why. Among hard-core Unix users and their wannabes, it became trendy to say, "I like using the C-Shell for regular work, but I use the Bourne shell for programming."

A watershed occurred in 1995, when Tom Christiansen, a highly respected Unix programmer and one of the fathers of the Perl programming language, wrote a widely circulated essay entitled "Csh Programming Considered Harmful". The title was taken from a very well-known computer paper, "Go To Statement Considered Harmful", a short essay by the Dutch programmer Edsger Dijkstra(*). In 1968, Dijkstra's paper had changed the world of programming, leading to the popularization of what became known as structured programming. In 1995, Christiansen's paper, though not as seminal, led to the eventual abandonment of both the C-Shell and the Tcsh for programming.

Today, the C-Shell and the Tcsh are not used nearly as widely as they once were and, since the mid-1990s, Tcsh development has slowed to a virtual standstill. Still, the C-SHELL FAMILY is held in high regard by many advanced Unix users and, for that reason, I have devoted a chapter of this book to show you how to use the shell, should you wish to do so.

On some systems, csh and tcsh are two separate programs. On many Unix systems, however, tcsh has completely replaced csh. That is, if you run csh, you will actually get tcsh. You can tell if this is the case on your system by looking at the csh man page (see Chapter 9).

Even today, the C-Shell is still important. Indeed, when you read about other shells, you will often see that they contain features taken from the C-Shell that Bill Joy designed so many years ago. For example, on the Web site for the Zsh, you will read, "Many of the useful features of bash, ksh, and tcsh were incorporated into zsh."

What's in a Name?

C-Shell, Tcsh

The name C-Shell comes from the fact that Bill Joy designed the shell's programming facilities to work like those of the C programming language. I imagine that Joy liked the name "C-Shell" because it sounds like "sea shell", and everyone likes sea shells.

But what about the Tcsh?

When Ken Greer wrote the original Tcsh for Unix, he was also using an operating system called TENEX on a PDP-10 computer from DEC. The TENEX command interpreter used very long command names because they were easy to understand. The commands, however, were a bother to type, so TENEX had a facility, called "command completion" to do a lot of the work. All you had to do was type a few letters and press the <Esc> key. The command interpreter would then expand what you had typed into the full command.

Greer added this feature to the new C-Shell, and when it came time to name the shell, he called it tcsh, the "t" referring to TENEX.

What's in a Name?

C, C++, C#

Both the C-Shell and the Tcsh are named after the C programming language. But how did such an odd name arise for a language?

In 1963, a programming language called CPL was developed in England as part of a project involving researchers from Cambridge and the University of London. CPL stood for "Combined Programming Language" and was based on Algol 60, one of the first well-designed, modern programming languages.

Four years later, in 1967, a programmer at Cambridge named Martin Richards created BCPL, "Basic CPL". BCPL itself gave rise to yet another language, known by the single letter, B.

The B language was taken to Bell Labs, where Ken Thompson and Dennis Ritchie made modifications and renamed it NB. In the early 1970s, Thompson (the original Unix developer) used NB to rewrite the basic part of Unix for its second edition. Up until then, all of Unix had been written in assembly language. Not long afterwards, the NB language was extended and renamed C. C soon became the language of choice for writing new Unix utilities, applications and even the operating system itself.

People asked, where did the name C come from? Was it the next letter after B in the alphabet, or was it the second letter of BCPL? This question had philological implications of cosmic importance: would the successor to C be named D or P?

The question proved to be moot when, in the early 1980s, Bjarne Stroustrup (also of Bell Labs) designed the most popular extension of C, an object-oriented language, which he called C++, pronounced "C-plus-plus". (In the C language, ++ is an operator that adds 1 to a variable. For instance, to add 1 to the variable total, you can use the command total++.)

In 2002, Microsoft created a special version of C++ as part of their .NET initiative. They called the new language C#, which is pronounced "C sharp" (like the music term). If you want, you can imagine two small "++" designations, one on top of the other, to form the "#" symbol.

Thus, when you see the names C, C++ or C#, you can recognize them as examples of those wonderful programming puns that make people scratch their heads and wonder if Man is really Nature's last word.

There are tens and tens of different Unix shells, of which we have discussed the most important ones: the Bourne shell, the Korn shell, the FreeBSD Shell, Pdksh, the Zsh, Bash, the C-Shell, and the Tcsh.

For reference, Figure 11-1 shows each of these shells along with the name of its program(*). To run the shell, if it exists on your system, just type in the name, for example:

There are a large number of Unix shells. This table shows the most popular shells, along with the names of the actual shell programs.

On some Unix systems, the various shells are all installed under their own names. The sh program is different from ksh or bash, and csh is different from tcsh. So if you want to use an old Bourne shell, you type sh; if you want to use Bash, you type bash. Similarly, you can use either csh (the standard C-Shell) or tcsh (the enhanced C-Shell).

On many systems, however, the newer shells have replaced the old ones, and you won't find the Bourne shell or the C-Shell Instead, if you type sh, you will get either Bash or the Korn shell; and if you type csh, you will get the Tcsh. To see if this is the case on your system, just look at the man page for the shell in question. For example, on Linux systems, if you ask for the sh man page, you get the bash man page; if you ask for the csh man page, you get the tcsh man page.

To display the man page for a particular shell, use the man command (Chapter 9) with the name of the appropriate program. For example:

Since shells are so complex, the man page will actually be the size of a small manual. Don't be overwhelmed: a lot of what you see is reference material for advanced users.

So, which shell should you use? If you are a beginner, it really doesn't matter, as all shells have the same basic functionality. However, as you begin to progress as a Unix user, the details do begin to matter and you need to make a commitment.

If you like to go with the flow, stick with the default and use whatever you get on your system when you type sh. Most likely this will be Bash with Linux, the FreeBSD Shell with FreeBSD, and the Korn shell with a commercial Unix system.

If you are adventurous, however, there are many shells for you to try. For example, although the C-Shell is no longer a default shell, many people do enjoy using it, and you may find that tcsh or csh is already available on your system. If you want to go further afield, just search the Internet for Unix or Linux shells, and I guarantee you'll find something new to try. (If you are adventurous and you can't make up your mind, try the Zsh.)

In a moment, I am going to show you how to change your shell. Before I do, I'd like to answer an interesting question: How complex are each of the shells? A complicated program will have a lot of capability, but it will also demand more of your time to master. Moreover, like many Unix programs, the shells have a lot of esoteric features and options that you will never really need. These extra facilities are often a distraction.

One crude way to measure the complexity of a program is by looking at the length of the documentation. The table in Figure 11-2 shows the approximate number of bytes (characters) in the manual pages for each of the shells. For comparison, I have normalized the numbers, assigning the smallest number a value of 1.0. (Of course, these numbers change from time to time as new versions of the documentation are released.)

One way to estimate the complexity of a program is to look at the size of its documentation. Here are statistics showing the relative complexity of the most popular Unix shells.

From these numbers, it is easy to see that the C-Shell and the FreeBSD Shell provide a nice middle ground between the older, less capable Bourne shell and the other, more complex shells.

Of course, one can argue that none of this matters, because all modern shells are backwards compatible, either with the Bourne shell or with the C-Shell. If you don't want the added features, you can ignore them and they won't bother you.

However, documentation is important. The manual pages for the more complex shells take a long time to read and are very difficult to understand. In fact, even the manual page for the Bourne shell is too large for a normal human being to peruse comfortably. So take another look at the numbers in Figure 11-2, and think about the following questions:

Assuming that the FreeBSD Shell, Bash, and the Zsh have most of the modern features knowledgeable Unix users require, what can you say about the type of person who chooses to use FreeBSD and the FreeBSD Shell?

What about a person who chooses to use Bash because it is the default on his or her system?

And what sort of person, do you think, enjoys downloading, installing and learning about a tool as complex as the Zsh (which is not the default on any system)?

Whenever you log in, a shell will be started for you automatically. This shell is called your LOGIN SHELL. An important question to answer is, which particular shell is your login shell? Is it Bash, the Korn shell, the C-Shell, or the Tcsh?

Unless you have changed the default, your login shell will be whichever shell is assigned to your userid. If you use Linux, your login shell will probably be Bash. If you use a commercial Unix, your login shell will probably be the Korn shell. If you use FreeBSD, it will probably be the Tcsh.

If you use a shared system, your system administrator will have set your login shell. As you know, on your own computer, you are the admin (see Chapter 4), so unless you have changed the default shell, it will be whatever was set automatically when you installed the system.

There are two ways in which you might change your shell. You may want to use a different shell temporarily, perhaps to experiment with it. Or, you may find that you like a new shell better than your current shell, and you want to make a permanent change.

Let's say, for example, you decide to try the Zsh. You download it from the Internet and install it on your system. From time to time, you change to the Zsh temporarily just for fun. Eventually, you come to like the Zsh so much that you want it to be your permanent login shell. In this section, I'll show you how to change your shell temporarily. In the next section, I'll show you how to do it permanently.

To start, remember that a shell is just a program that you can run like any other program. This means that, at any time, you can pause your current shell and start another one simply by running the new shell. For example, let's say you have just logged in, and your login shell is Bash. You enter a few commands, and then you decide you want to try the Tcsh (assuming it is available on your system). Just enter:

Your current shell (Bash) is paused and the new shell (the Tcsh) starts. You can now do whatever you want using the Tcsh. When you are ready to switch back to Bash, just press ^D (see Chapter 7) to indicate that there is no more data. The Tcsh shell will now end, and you will be returned to your original Bash shell. It's that easy.

If you want to experiment, you can see what shells are available on your system by using the following command:

If you are experimenting, and you get confused as to which shell you are using, you can use the following command at any time to show you the name of the current shell:

Unix uses two files to keep track of all the userids in the system. The first file /etc/passwd — the PASSWORD FILE — contains basic information about each userid. The second file /etc/shadow — the SHADOW FILE — contains the actual passwords (encrypted, of course).

When you log in, Unix retrieves information about your userid from these files. In particular, the /etc/passwd file contains the name of your login shell. Thus, to change your login shell, all you need to do is make a simple change in the /etc/passwd file. However, you don't do this directly. It would be too risky, as screwing up the /etc/passwd file can wreak havoc with your system. Instead, you use a special command, which I will explain in a moment.

Before I do, I want to say a word about file names. The way in which I have written the names of the two files I just mentioned is called a "pathname". A pathname shows the exact location of a file within the file system. We will discuss this idea in detail when we talk about the Unix file system in Chapter 23. For now, all you need to know is that the pathname /etc/passwd refers to the passwd file within the /etc directory. A directory is what a Windows or Mac user would call a folder. (This idea, like many others, was taken from Unix.)

When you change your shell, you need to specify the name of the shell program as a pathname. The pathnames of the available shells are stored in a file named /etc/shells(*). To display this file, use the less command (which we will meet formally in Chapter 21).

From this output, you can see that (in this case) there are four available shells: sh, bash, tcsh and csh.

To change your login shell, you use the chsh (change shell) command. The syntax(*) is:

where userid is the userid for which you want to make the change; shell is the pathname of the new login shell.

Notes: (1) You can only change the shell for your own userid. To change the shell for another userid, you must be superuser. (2) On some systems, chsh will not allow you to change to a shell unless it is listed in the /etc/shells file. On other systems, chsh will allow you to make such a change, but it will give you a warning. Thus, if you download and install a shell on your own, it behooves you to put the pathname of the shell in the /etc/shells files.

By default, chsh assumes that you want to change your own login shell, so you don't have to specify the userid. For example, to change your login shell to /bin/tcsh, use:

If you leave out the -s option and the name of the shell, chsh will prompt you (ask you) for it. For example, say you are logged in as harley, and you enter:

At this point chsh is telling you two things. First, you are about to change the login shell for userid harley. Second, the current login shell is /bin/bash.

You now have two choices. If you enter the pathname of a new shell, chsh will make the change for you. For example, to change your login shell to the Tcsh, enter:

If you simply press <Enter> without typing anything, chsh will not make a change. This is a good way to see the name of your current login shell.

With Linux, the chsh command has another option that is useful. To display a list of all the available shells, you can use the -l (list) option:

Some Unix systems don't have a chsh command. Instead, you change your login shell by using a variation of the passwd command (which we discussed in Chapter 4). For example, with AIX, you use passwd ‑s; with Solaris, you use passwd -e. For more details, see your passwd man page.

If you are a system administrator, and you are called upon to change someone else's login shell, you can use the usermod -s. Again, see the man page for details.

What are the two principal shell families? Name the most commonly used shells in each family.

How do you change your shell temporarily? How do you change your shell permanently?

Change your default shell to another shell. Log out and log in again. Check to make sure your default shell has been changed.

Change your default shell back to what it was. Log out and log in again. Check to see that your default shell was changed back correctly.

Over the years, many different Unix shells have been created. Why is this necessary? Why not just have one main shell that can be enhanced from time to time?

Program A has been replaced by program B. What are the advantages if program B is backwards compatible with program A? What are the disadvantages?