Probably the single most important concept for would-be power users to grasp is that you don't talk to UNIX directly. Instead, you talk to a program called the shell. The shell protects UNIX from the user (and the user from UNIX).
The UNIX operating system proper is referred to as the kernel (1.14). Usually, only programs talk to the kernel (through system calls (52.9)). Users talk to the shell, which interprets their commands and either executes them directly or passes them on to other programs. These programs in turn request lower-level services from the kernel.
For example, when you type a command to display files whose four-character filenames start with the letter "m":
??? | % |
---|
it is the shell that finds the filenames, makes a complete list of them, and calls the cat (25.2) command to ask it to print the expanded list. The cat command calls on the kernel to find each file on the disk and print its contents as a stream of characters on the display.
Why is this important? First of all, you can choose between several different shells (1.8), each of which may have different rules for interpreting command lines.
Second, the shell has to interpret the command line you type and package it up for the command you are calling. Because the shell reads the command line first, it's important to understand just how the shell changes what it reads.
For example, one basic rule is that the shell uses "white space" (spaces or tabs) to separate each "argument" of a command. But sometimes, you want the shell to interpret its arguments differently. For example, if you are calling grep (27.1), a program for searching through files for a matching line of text, you might want to supply an entire phrase as a single argument. The shell lets you do this by quoting (8.14) arguments. For example:
%grep "UNIX Power Tools" articles/*
Understanding how the shell interprets the command line, and
when to keep it from doing so, can be very important in a lot
of special cases, especially when dealing with
wildcards (1.16)
like the *
(asterisk) above.
Article
8.5
explains more about how the shell interprets what you type.
You can think of the relationship of the kernel, the shell, and various UNIX utilities and applications as looking like Figure 1.1.
Note that there are some interactive commands that take input directly from the user, without intervention from the shell. The shell's only job is to start them up. A text editor, a mail program, or almost any application program (desktop publishing, spreadsheet) includes its own command interpreter with its own rules.
-