1.4. Communication with Unix
Probably the single most important concept for would-be power users to grasp is that you don't "talk" directly to the Unix operating system. Instead, you talk to a program -- and that program either talks to Unix itself or it talks to another program that talks to Unix. (When we say "talk" here, we mean communication using a keyboard and a mouse.)
There are three general kinds of programs you'll probably "talk" to:
The core of the Unix operating system is referred to as the kernel (Section 1.10). Usually, only programs talk to the kernel (through system calls). Users talk to one of the three previous types of programs, which interprets their commands and either executes them directly or passes them on to other programs. These programs may, in turn, request lower-level services from the kernel.
Let's look at a specific example of using the shell. When you type a command to display files whose four-character filenames start with the letter "m":
??? Section 1.13
% cat m???
it is the shell that finds the filenames, makes a complete list of them, and calls the cat (Section 12.2) command 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 (Section 1.6), 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 "whitespace" (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 (Section 13.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 (Section 27.12) arguments. For example:
% grep "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 (Section 1.13), like the * (asterisk) in the previous example.
You can think of the relationship of the kernel, the shell, and various Unix utilities and applications as looking like Figure 1-1.
Figure 1-1. Relationship of kernel, shell, utilities, and applications
Figure 1-1 shows that a user can interact with the shell, as well as directly with interactive commands like cat and ls. The shell transfers control to the commands it starts for you -- then those commands may write the output you see. The shell also has some built-in commands (Section 1.9) that run directly within the shell itself. All of the commands shown in Figure 1-1 interact directly with Unix itself.
--TOR and JP
Copyright © 2003 O'Reilly & Associates. All rights reserved.