unix time_share_system .htm

讲解关于UXIX操作系统的资料,包含如何基本操作以及编程.

<DL>
  <DT>
  <DD><TT><PRE>ls
</PRE></TT></DD></DL>ordinarily lists, on the typewriter, the names of the files 
in the current directory. The command: 
<DL>
  <DT>
  <DD><TT><PRE>ls &gt;there
</PRE></TT></DD></DL>creates a file called <I>there</I> and places the listing 
there. Thus the argument <I>&gt;there</I> means ``place output on 
<I>there</I>.'' On the other hand: 
<DL>
  <DT>
  <DD><TT><PRE>ed
</PRE></TT></DD></DL>ordinarily enters the editor, which takes requests from the 
user via his keyboard. The command 
<DL>
  <DT>
  <DD><TT><PRE>ed &lt;script
</PRE></TT></DD></DL>interprets <I>script</I> as a file of editor commands; thus 
``&lt;script'' means ``take input from <I>script.''</I> 
<P></P>
<P>Although the file name following ``&lt;'' or ``&gt;'' appears to be an 
argument to the command, in fact it is interpreted completely by the shell and 
is not passed to the command at all. Thus no special coding to handle I/O 
redirection is needed within each command; the command need merely use the 
standard file descriptors 0 and 1 where appropriate. </P>
<P>File descriptor 2 is, like file 1, ordinarily associated with the terminal 
output stream. When an output-diversion request with ``&gt;'' is specified, file 
2 remains attached to the terminal, so that commands may produce diagnostic 
messages that do not silently end up in the output file. </P>
<H4>6.2 Filters </H4>
<P>An extension of the standard I/O notion is used to direct output from one 
command to the input of another. A sequence of commands separated by vertical 
bars causes the shell to execute all the commands simultaneously and to arrange 
that the standard output of each command be delivered to the standard input of 
the next command in the sequence. Thus in the command line: 
<DL>
  <DT>
  <DD><TT><PRE>ls | pr -2 | opr
</PRE></TT></DD></DL><I>ls</I> lists the names of the files in the current 
directory; its output is passed to <I>pr</I>, which paginates its input with 
dated headings. (The argument ``-2'' requests double-column output.) Likewise, 
the output from <I>pr</I> is input to <I>opr</I>; this command spools its input 
onto a file for off-line printing. 
<P></P>
<P>This procedure could have been carried out more clumsily by: 
<DL>
  <DT>
  <DD><TT><PRE>ls &gt;temp1
pr -2 &lt;temp1 &gt;temp2
opr &lt;temp2
</PRE></TT></DD></DL>followed by removal of the temporary files. In the absence 
of the ability to redirect output and input, a still clumsier method would have 
been to require the <I>ls</I> command to accept user requests to paginate its 
output, to print in multi-column format, and to arrange that its output be 
delivered off-line. Actually it would be surprising, and in fact unwise for 
efficiency reasons, to expect authors of commands such as <I>ls</I> to provide 
such a wide variety of output options. 
<P></P>
<P>A program such as <I>pr</I> which copies its standard input to its standard 
output (with processing) is called a <B>filter</B>. Some filters that we have 
found useful perform character transliteration, selection of lines according to 
a pattern, sorting of the input, and encryption and decryption. </P>
<H4>6.3 Command separators; multitasking </H4>
<P>Another feature provided by the shell is relatively straightforward. Commands 
need not be on different lines; instead they may be separated by semicolons: 
<DL>
  <DT>
  <DD><TT><PRE>ls; ed
</PRE></TT></DD></DL>will first list the contents of the current directory, then 
enter the editor. 
<P></P>
<P>A related feature is more interesting. If a command is followed by 
``<I>&amp;</I>,'' the shell will not wait for the command to finish before 
prompting again; instead, it is ready immediately to accept a new command. For 
example: 
<DL>
  <DT>
  <DD><TT><PRE>as source &gt;output &amp;
</PRE></TT></DD></DL>causes <I>source</I> to be assembled, with diagnostic 
output going to <I>output</I>; no matter how long the assembly takes, the shell 
returns immediately. When the shell does not wait for the completion of a 
command, the identification number of the process running that command is 
printed. This identification may be used to wait for the completion of the 
command or to terminate it. The ``<I>&amp;</I>'' may be used several times in a 
line: 
<DL>
  <DT>
  <DD><TT><PRE>as source &gt;output &amp; ls &gt;files &amp;
</PRE></TT></DD></DL>does both the assembly and the listing in the background. 
In these examples, an output file other than the terminal was provided; if this 
had not been done, the outputs of the various commands would have been 
intermingled. 
<P></P>
<P>The shell also allows parentheses in the above operations. For example: 
<DL>
  <DT>
  <DD><TT><PRE>(date; ls) &gt;x &amp;
</PRE></TT></DD></DL>writes the current date and time followed by a list of the 
current directory onto the file <I>x</I>. The shell also returns immediately for 
another request. 
<P></P>
<H4>6.4 The shell as a command; command files </H4>
<P>The shell is itself a command, and may be called recursively. Suppose file 
<I>tryout</I> contains the lines: 
<DL>
  <DT>
  <DD><TT><PRE>as source
mv a.out testprog
testprog
</PRE></TT></DD></DL>The <I>mv</I> command causes the file <I>a.out</I> to be 
renamed <I>testprog.</I> <I>a.out</I> is the (binary) output of the assembler, 
ready to be executed. Thus if the three lines above were typed on the keyboard, 
<I>source</I> would be assembled, the resulting program renamed <I>testprog</I>, 
and <I>testprog</I> executed. When the lines are in <I>tryout</I>, the command: 
<DL>
  <DT>
  <DD><TT><PRE>sh &lt;tryout
</PRE></TT></DD></DL>would cause the shell <I>sh</I> to execute the commands 
sequentially. 
<P></P>
<P>The shell has further capabilities, including the ability to substitute 
parameters and to construct argument lists from a specified subset of the file 
names in a directory. It also provides general conditional and looping 
constructions. </P>
<H4>6.5 Implementation of the shell </H4>
<P>The outline of the operation of the shell can now be understood. Most of the 
time, the shell is waiting for the user to type a command. When the newline 
character ending the line is typed, the shell's <I>read</I> call returns. The 
shell analyzes the command line, putting the arguments in a form appropriate for 
<I>execute</I>. Then <I>fork</I> is called. The child process, whose code of 
course is still that of the shell, attempts to perform an <I>execute</I> with 
the appropriate arguments. If successful, this will bring in and start execution 
of the program whose name was given. Meanwhile, the other process resulting from 
the <I>fork</I>, which is the parent process, <I>wait</I>s for the child process 
to die. When this happens, the shell knows the command is finished, so it types 
its prompt and reads the keyboard to obtain another command. </P>
<P>Given this framework, the implementation of background processes is trivial; 
whenever a command line contains ``<I>&amp;</I>,'' the shell merely refrains 
from waiting for the process that it created to execute the command. </P>
<P>Happily, all of this mechanism meshes very nicely with the notion of standard 
input and output files. When a process is created by the <I>fork</I> primitive, 
it inherits not only the memory image of its parent but also all the files 
currently open in its parent, including those with file descriptors 0, 1, and 2. 
The shell, of course, uses these files to read command lines and to write its 
prompts and diagnostics, and in the ordinary case its children&shy;the command 
programs&shy;inherit them automatically. When an argument with ``&lt;'' or 
``&gt;'' is given, however, the offspring process, just before it performs 
<I>execute,</I> makes the standard I/O file descriptor (0 or 1, respectively) 
refer to the named file. This is easy because, by agreement, the smallest unused 
file descriptor is assigned when a new file is <I>open</I>ed (or 
<I>create</I>d); it is only necessary to close file 0 (or 1) and open the named 
file. Because the process in which the command program runs simply terminates 
when it is through, the association between a file specified after ``&lt;'' or 
``&gt;'' and file descriptor 0 or 1 is ended automatically when the process 
dies. Therefore the shell need not know the actual names of the files that are 
its own standard input and output, because it need never reopen them. </P>
<P>Filters are straightforward extensions of standard I/O redirection with pipes 
used instead of files. </P>
<P>In ordinary circumstances, the main loop of the shell never terminates. (The 
main loop includes the branch of the return from <I>fork</I> belonging to the 
parent process; that is, the branch that does a <I>wait</I>, then reads another 
command line.) The one thing that causes the shell to terminate is discovering 
an end-of-file condition on its input file. Thus, when the shell is executed as 
a command with a given input file, as in: 
<DL>
  <DT>
  <DD><TT><PRE>sh &lt;comfile
</PRE></TT></DD></DL>the commands in <I>comfile</I> will be executed until the 
end of <I>comfile</I> is reached; then the instance of the shell invoked by 
<I>sh</I> will terminate. Because this shell process is the child of another 
instance of the shell, the <I>wait</I> executed in the latter will return, and 
another command may then be processed. 
<P></P>
<H4>6.6 Initialization </H4>
<P>The instances of the shell to which users type commands are themselves 
children of another process. The last step in the initialization of the system 
is the creation of a single process and the invocation (via <I>execute</I>) of a 
program called <I>init</I>. The role of <I>init</I> is to create one process for 
each terminal channel. The various subinstances of <I>init</I> open the 
appropriate terminals for input and output on files 0, 1, and 2, waiting, if 
necessary, for carrier to be established on dial-up lines. Then a message is 
typed out requesting that the user log in. When the user types a name or other 
identification, the appropriate instance of <I>init</I> wakes up, receives the 
log-in line, and reads a password file. If the user's name is found, and if he 
is able to supply the correct password, <I>init</I> changes to the user's 
default current directory, sets the process's user ID to that of the person 
logging in, and performs an <I>execute</I> of the shell. At this point, the 
shell is ready to receive commands and the logging-in protocol is complete. </P>
<P>Meanwhile, the mainstream path of <I>init</I> (the parent of all the 
subinstances of itself that will later become shells) does a <I>wait</I>. If one 
of the child processes terminates, either because a shell found an end of file 
or because a user typed an incorrect name or password, this path of <I>init</I> 
simply recreates the defunct process, which in turn reopens the appropriate