You met the Linux command interpreter, or shell, early in this book. Like an MS-DOS Prompt window, the shell lets you issue commands that it interprets, or executes. By means of the shell, you use and control your system.
The MS-DOS shell has been fairly consistent over time; for example, the differences between MS-DOS v3 and MS-DOS v7 are few. The Unix shell, however, has experienced significantly more evolutionary development than MS-DOS. Today, you find both versions and variants of the Unix shell. The Unix shell variants have much in common, but each has a different authorship and history, and each reflects a different view of how users should interact with Unix.
Linux includes the most popular Unix shells, as shown in
Table 13.1. The most popular Linux shell is the BASH shell (the "Bourne Again SHell"), based on the original Unix Bourne shell. The BASH shell is largely compliant with the POSIX standard, which specifies the syntax and operation of a standard Unix shell and which has been widely implemented. Because of the popularity of the POSIX standard and the obvious advantage of working with a shell that's consistent across a variety of computing platforms, this chapter focuses on the BASH shell. Most Linux systems are configured to automatically start a BASH shell on your behalf when you log in; so, you don't generally need to be much concerned about choosing a shell. However, for information about the other available shells, you can consult the Linux man pages.
Table 13.1: Common Linux Shells
|
Shell name |
Program name(s) |
Description |
|
ASH shell |
/bin/ash
/bin/bsh |
Resembles the shell used by AT&T's System V Unix. |
|
BASH shell |
/bin/bash
/bin/bash2 |
The standard shell for Linux, based on the original Unix Bourne shell. According to its man page, BASH is "ultimately intended" to be POSIX compliant. |
|
C shell |
/bin/csh
/bin/tcsh |
The second Unix shell. Designed to facilitate interactive use, it added many new features and functions. Its syntax resembles that of the C programming language. |
|
Korn shell |
/bin/ksh |
The third Unix shell, added many of the features of the C shell to the original Bourne shell. |
|
Z shell |
/bin/zsh |
A feature-packed shell based on the Korn shell. |
If you're accustomed to the point-and-click world of graphical user interfaces, you may question the value of learning to use the Linux shell. Many users initially find the shell cumbersome, and some retreat to the familiar comfort of the graphical user interface, avoiding the shell whenever possible.
While it's true that the shell is an older style of interacting with a computer than the graphical user interface, the graphical user interface is actually the more primitive interface. The graphical user interface is easy to learn and widely used, but the shell is vastly more sophisticated. Using a graphical user interface is somewhat like communicating in American Indian sign language. If your message is a simple one, like "we come in peace," you can communicate it by using a few gestures. However, if you attempted to give Lincoln's Gettysburg address - a notably short public discourse - by means of American Indian sign language, you'd find your task quite formidable.
American Sign Language, used to communicate with those who have a hearing impairment, is a much richer language than American Indian sign language. Unfortunately, programmers have not yet risen to the challenge of creating graphical user interfaces that are equally sophisticated. The designer of a program that provides a graphical user interface must anticipate all the possible ways in which the user will interact with the program and provide ways to trigger the appropriate program responses by means of pointing and clicking. Consequently, the user is constrained to working only in predicted ways. The user is therefore unable to adapt the graphical user interface program to accommodate unforeseen tasks and circumstances. In a nutshell, that's why many system administration tasks are performed using the shell: system administrators, in fulfilling their responsibility to keep a system up and running, must continually deal with and overcome the unforeseen.
The shell reflects the underlying philosophy of Unix, which provides a wide variety of small, simple tools (that is, programs), each performing a single task. When a complex operation is needed, the tools work together to accomplish the complex operation as a series of simple operations, one step at a time. Many Unix tools manipulate text and, since Unix stores its configuration data in text form rather than in binary form, the tools are ideally suited for manipulating Unix itself. The shell's ability to freely combine tools in novel ways is what makes Unix powerful and sophisticated. Moreover, as you'll learn, the shell is extensible: You can create shell scripts that let you store a series of commands for later execution, saving you the future tedium of typing or pointing and clicking to recall them.
The contrary philosophy is seen in operating systems such as Microsoft Windows, which employ elaborate, monolithic programs that provide menus, submenus, and dialog boxes. Such programs have no way to cooperate with one another to accomplish complex operations that weren't anticipated when the programs were designed. They're easy to use so long as you remain on the beaten path, but once you step off the trail you find yourself in a confusing wilderness.
Of course, not everyone shares this perspective. The USENET newsgroups, for example, are filled with postings debating the relative merits of graphical user interfaces. Some see the Unix shell as an arcane and intimidating monstrosity. But, even if they're correct, it's inarguable that when you learn to use the shell, you begin to see Unix as it was intended (whether that's for better or for worse).
The author's perspective is pragmatic: When performing common, routine operations, a graphical user interface that minimizes typing can be a relief; but, when faced with a complex, unstructured problem that requires creative solution, the shell is more often the tool of choice. By creating solutions in the form of shell scripts, solutions can be stored for subsequent reuse. Perhaps even more important, shell scripts can be studied to quickly bone up on forgotten details, expediting the solution of related problems.
