04_583204 ch01.qxd 3/18/05 9:26 PM Page 1 1 Introducing Shells This chapter introduces the shell, obviously the most important component for shell scripting. It describes the choices among shells, as well as how to find out which shells are available. In mod- ern graphical desktop environments, it is not always easy to find the shell, but you’d be surprised at how many systems actually support shells, from Zaurus PDAs to Audrey network appliances to the beautifully designed Mac OS X systems. No matter how nice a graphical user interface your system sports, adding the power of a shell can dramatically increase the speed and efficiency of what you can do on your computer. Shells provide greater control over your system and allow you to do some things that simply cannot be done from the graphical environment. Shells often allow you to perform tasks remotely, which is especially useful if you need to do something to a large number of computers or computers located at another site. Even in an environment such as Apple’s Mac OS X, shell scripting is a useful, powerful tool in anyone’s kit. Apple had the forethought to make it possible to connect shell scripts to the GUI environment via a number of custom utilities that ship with the OS, so you can link UI-level scripts done in AppleScript to the shell environment for more power than either environment alone would have. Because shells exist to accept your commands, each shell provides help for entering complicated commands, a set of sometimes-complicated shortcuts that can speed up your work immensely. These shortcuts include special editing modes, based on the two traditional text editors, emacs and vi. In this chapter, I discussCOPYRIGHTED the following: MATERIAL ❑ Understanding shells, including a number of different shells with interesting names such as bash, ksh, and csh. ❑ Finding your shell, which is not always easy in a graphical desktop environment. ❑ Entering commands into shells, editing those commands, and storing a history of your commands. ❑ Using wildcards in your commands. 04_583204 ch01.qxd 3/18/05 9:26 PM Page 2 Chapter 1 If you’re already familiar with the shell, parts of this chapter will likely cover material you already know. If so, you may want to skim through for anything new and then jump to the next chapter. What Is a Shell? A shell is a program that takes commands typed by the user and calls the operating system to run those commands. The shell interprets your commands. For example, you may use the shell to enter a com- mand to list the files in a directory, such as ls, or a command to copy a file, such as cp. There are a number of different shells, which are introduced later in this chapter. Here’s a short example to give you a taste of using a shell. Launch a shell window, or access a shell. Type the following command to list all the files in the current directory: If you don’t know how to launch a shell window on the desktop or log into a shell, that’s okay. See the section Determining Which Shell You Are Running for more on how to track down the elusive shell on your system. $ ls configuration eclipse icon.xpm plugins startup.jar cpl-v10.html features notice.html readme workspace In this example, you simply type ls and press Enter (or Return, depending on your keyboard). The $ is the shell prompt, which tells you the shell awaits your commands. The remaining lines are the names of the files in the current directory. Just going over the basics of running a simple command introduces a lot of complex topics, as shells are not all that simple. If the following sections don’t make sense, don’t worry. Each topic will be covered in detail later in this book. The shell displays its prompt, shown here as $, and then passively awaits your commands. When you type a command and press Enter (or Return on Mac OS X systems), you are telling the shell to execute your command. The shell looks for a program — that is, a file with execute permissions — with the name ls. The shell looks at all the directories in your command path. The shell runs the first program found that matches the name (and the execute permissions) and then displays the results of the program to your screen, as in the second and third lines in the code example. The command path is stored in the environment variable named PATH. Read more on environment variables in Chapter 4. The way the shell interprets commands and executes programs is fairly complicated. Back when shells were first created, their developers thought shells were pretty nifty. The fact that you’re reading this book now, more than 30 years later, means those developers were right. 2 04_583204 ch01.qxd 3/18/05 9:26 PM Page 3 Introducing Shells Back in the ancient days of computing, computers ran no shell, or the shell, if it existed, was so connected to the operating system that it was indistinguishable. You can still see the legacy of these single-shell sys- tems in the MS-DOS shell on Windows. Don’t worry, I’ll show you how to break free of the single-shell monopoly on Windows. A shell acts as a form of wrapper around the OS, hence the term shell. (Nowadays, with object-oriented parlance, a shell would be called something like a CommandReadingOperatingSystemDecorator.) Shells were designed long before graphical interfaces existed. As graphical environments mature, most users explicitly run shells less and less for their daily work. But a shell can automate some very complex sequences of commands. In addition, most Linux systems are designed to be updated from typed-in commands — that is, from a shell. Furthermore, whether you know it or not, a shell often powers many of the graphical commands users run. Learning the shell can help you better understand your computer. Why Use Shells? Unix was the first popular operating system to break free of the single-shell monopoly. In Unix (and Linux), a shell is simply a program. What makes the shell special is that a shell is the program run when most users log in. (You can configure which program [shell] gets run.) As such, the shell fits in well with the Unix philosophy that each command should do one thing and do it well. Complex commands are then built by combining small commands. In this context, a shell is sim- ply another command — a command that facilitates combining other commands. You can use shell scripts to automate administrative tasks, encapsulate complex configuration details, and get at the full power of the operating system. The ability to combine commands allows you to create new commands, thereby adding value to your operating system. Furthermore, combining a shell with a graphical desktop environment allows you to get the best of both worlds. You get all the friendliness of the graphical user interface and all the power of the command line. On Unix and Unix-like systems such as Linux, a shell interprets your commands, running one or more programs for each command you enter. In addition, most shells allow you to group a number of com- mands in a file, called a shell script. When you run the shell script file, the shell executes the commands in the script file in order. For example, you can create a shell script to look for all files that have the text string “abc” in the file name and then sort those files by the date they were last modified and back up those files that contain the most recent changes. The same script could send you an email when it finishes its work and also deliver an affirmation that you are a good person. Each shell provides a different syntax as to what you can enter. The syntax supported by most shells includes a lot of support for working with files. For example, you can list all the files that start with an uppercase A or a lowercase a, using a simple command like the following: $ ls [Aa]* 3 04_583204 ch01.qxd 3/18/05 9:26 PM Page 4 Chapter 1 The ls part tells the shell to launch the command named ls (which lists file names). The [Aa]* part is interpreted by the shell and is part of the syntax supported by most shells. The bracket syntax, [Aa], is considered a regular expression. Many commands, such as grep, support regular expressions, sometimes with a slightly different syntax. See the Working with Wildcards section for more on regular expressions and wildcards. What Kind of Shells Are There? Since there is no monopoly on shells, you are free to run any shell you desire. That’s all well and good, but choosing a shell without knowing the alternatives isn’t very helpful. The following sections introduce the main shells. The Bourne Shell The original Unix shell is known as sh, short for shell or the Bourne shell, named for Steven Bourne, the creator of sh. As shells go, sh remains fairly primitive, but it was quite advanced for the 1970s, when it first appeared (as part of the Seventh Edition Bell Labs Research version of Unix). The Bourne shell has been considered a standard part of Unix for decades. Thus, sh should be available on almost all systems that support Unix or Unix-like commands, including Linux, Unix, and Mac OS X systems. The Bourne shell feature set, therefore, forms the least common denominator when it comes to shells.