 |  |
| |
What the Shell Does
How the Shell Executes Other Commands
What's a Shell, Anyway?
Command Evaluation and Accidentally Overwriting Files
Output Command-Line Arguments One by One
Controlling Shell Command Searches
Wildcards Inside Aliases
eval: When You Need Another Chance
Which One Will bash Use?
Which One Will the C Shell Use?
Is It "2>&1 file" or "> file 2>&1"? Why?
Bourne Shell Quoting
Differences Between Bourne and C Shell Quoting
Quoting Special Characters in Filenames
Verbose and Echo Settings Show Quoting
Here Documents
"Special" Characters and Operators
How Many Backslashes?
As we've said, the shell is just another program. It's responsible for interpreting the commands you type. There are several commonly used shells, primarily based on two or three major families and a wide variety of other projects:
The Bourne shell (sh) and its derivatives and progeny (including bash, ash, and even the Korn shell ksh)
The Korn shell (ksh) and variants (including pdksh and zsh[82])
[82]It's difficult to trace the development of all these shells in a simple manner. Their authors have borrowed ideas and syntax from the others -- and sometimes code -- and sometimes a shell starts out trying to emulate another but evolves away from its original inspiration (or the inspiration evolves away from the aspirant).
Specialized shells based on languages such as Python, TCL, perl, and so on.
Shells invented to meet specific needs such as restricted command access (rsh), recovery after a system failure (sash), and downloading, installing, and configuring software libraries.
If you can think of a reason to have a specialized shell, someone probably has already written one to meet that need.
Interpreting your commands might seem simple enough, but a lot of things happen between the time you press RETURN and the time the computer actually does what you want. The process of interpretation is very complex: the shell has to break the command into words and expand aliases (Section 29.2), history operators (Section 30.8), and shell and environment variables (Section 35.3, Section 35.9). It also sets up standard input and output streams (Section 43.1) and performs a lot of other tasks. Indeed, if a command looks right but doesn't work right, the cause is probably either one of the following:
You don't understand how the shell is processing your command line.
I'd say that file permission problems are more common, but it's a close call. File permission problems are usually easy to understand, once you know what to look for, but the rules by which a shell interprets your command line are another thing altogether. Lest I scare you, we'll try to go slow with this material. Although it's difficult, understanding how the shell parses your commands is important to becoming a power user.
In this chapter, we'll look at how a Unix shell interprets commands. Shells have similar interpretation rules. The C shell can be tricky at times, mostly because its behavior isn't as well defined as the others. And zsh has some twists that others don't -- they're included by design, but they can surprise users of other shells. However, there's nothing "magical" about these rules. Tomorrow morning, you may grab some new shell from the Net and find out that it has a new and different way of interpreting commands. For better or worse, that's what Unix is all about.
As part of this discussion, we'll cover quoting, which is the mechanism by which you can turn off the special meanings that the shell assigns to some characters. Quoting is an integral part of command-line processing; it allows you to control what the shell will do to your commands.
--ML and SJC
|  | |
| VI. Scripting |  | 27.2. How the Shell Executes Other Commands |
Copyright © 2003 O'Reilly & Associates. All rights reserved.