Follow Techotopia on Twitter

On-line Guides
All Guides
eBook Store
iOS / Android
Linux for Beginners
Office Productivity
Linux Installation
Linux Security
Linux Utilities
Linux Virtualization
Linux Kernel
System/Network Admin
Programming
Scripting Languages
Development Tools
Web Development
GUI Toolkits/Desktop
Databases
Mail Systems
openSolaris
Eclipse Documentation
Techotopia.com
Virtuatopia.com

How To Guides
Virtualization
General System Admin
Linux Security
Linux Filesystems
Web Servers
Graphics & Desktop
PC Hardware
Windows
Problem Solutions

  




 

 


Previous: 12.5 Configuring a Dial-In Shell Server Chapter 13 Next: 13.2 Using the Shell
 

13. Conquering the BASH Shell

This chapter describes the powerful BASH shell, providing a much more detailed explanation than that provided in Chapter 4, Issuing Linux Commands. The chapter also briefly explains shell variables, shell scripts, and shell aliases, preparing you for an in-depth, continuing study of Linux.

13.1 The Linux Shell

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.

13.1.1 A Variety of Shells

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.

13.1.2 Why Learn to Use the 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.


Previous: 12.5 Configuring a Dial-In Shell Server Learning Debian GNU/Linux Next: 13.2 Using the Shell
12.5 Configuring a Dial-In Shell Server Book Index 13.2 Using the Shell

 
 
  Published under the terms of the Creative Commons License Design by Interspire