unix time_share_system .htm

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

input and output files and types another log-in message. Thus a user may log out 
simply by typing the end-of-file sequence to the shell. </P>
<H4>6.7 Other programs as shell </H4>
<P>The shell as described above is designed to allow users full access to the 
facilities of the system, because it will invoke the execution of any program 
with appropriate protection mode. Sometimes, however, a different interface to 
the system is desirable, and this feature is easily arranged for. </P>
<P>Recall that after a user has successfully logged in by supplying a name and 
password, <I>init</I> ordinarily invokes the shell to interpret command lines. 
The user's entry in the password file may contain the name of a program to be 
invoked after log-in instead of the shell. This program is free to interpret the 
user's messages in any way it wishes. </P>
<P>For example, the password file entries for users of a secretarial editing 
system might specify that the editor <I>ed</I> is to be used instead of the 
shell. Thus when users of the editing system log in, they are inside the editor 
and can begin work immediately; also, they can be prevented from invoking 
programs not intended for their use. In practice, it has proved desirable to 
allow a temporary escape from the editor to execute the formatting program and 
other utilities. </P>
<P>Several of the games (e.g., chess, blackjack, 3D tic-tac-toe) available on 
the system illustrate a much more severely restricted environment. For each of 
these, an entry exists in the password file specifying that the appropriate 
game-playing program is to be invoked instead of the shell. People who log in as 
a player of one of these games find themselves limited to the game and unable to 
investigate the (presumably more interesting) offerings of the Unix system as a 
whole. </P>
<H4>VII. TRAPS </H4>
<P>The PDP-11 hardware detects a number of program faults, such as references to 
non-existent memory, unimplemented instructions, and odd addresses used where an 
even address is required. Such faults cause the processor to trap to a system 
routine. Unless other arrangements have been made, an illegal action causes the 
system to terminate the process and to write its image on file <I>core</I> in 
the current directory. A debugger can be used to determine the state of the 
program at the time of the fault. </P>
<P>Programs that are looping, that produce unwanted output, or about which the 
user has second thoughts may be halted by the use of the <I>interrupt</I> 
signal, which is generated by typing the ``delete'' character. Unless special 
action has been taken, this signal simply causes the program to cease execution 
without producing a <I>core</I> file. There is also a <I>quit</I> signal used to 
force an image file to be produced. Thus programs that loop unexpectedly may be 
halted and the remains inspected without prearrangement. </P>
<P>The hardware-generated faults and the interrupt and quit signals can, by 
request, be either ignored or caught by a process. For example, the shell 
ignores quits to prevent a quit from logging the user out. The editor catches 
interrupts and returns to its command level. This is useful for stopping long 
printouts without losing work in progress (the editor manipulates a copy of the 
file it is editing). In systems without floating-point hardware, unimplemented 
instructions are caught and floating-point instructions are interpreted. </P>
<H4>VIII. PERSPECTIVE </H4>
<P>Perhaps paradoxically, the success of the Unix system is largely due to the 
fact that it was not designed to meet any predefined objectives. The first 
version was written when one of us (Thompson), dissatisfied with the available 
computer facilities, discovered a little-used PDP-7 and set out to create a more 
hospitable environment. This (essentially personal) effort was sufficiently 
successful to gain the interest of the other author and several colleagues, and 
later to justify the acquisition of the PDP-11/20, specifically to support a 
text editing and formatting system. When in turn the 11/20 was outgrown, the 
system had proved useful enough to persuade management to invest in the 
PDP-11/45, and later in the PDP-11/70 and Interdata 8/32 machines, upon which it 
developed to its present form. Our goals throughout the effort, when articulated 
at all, have always been to build a comfortable relationship with the machine 
and to explore ideas and inventions in operating systems and other software. We 
have not been faced with the need to satisfy someone else's requirements, and 
for this freedom we are grateful. </P>
<P>Three considerations that influenced the design of Unix are visible in 
retrospect. </P>
<P>First: because we are programmers, we naturally designed the system to make 
it easy to write, test, and run programs. The most important expression of our 
desire for programming convenience was that the system was arranged for 
interactive use, even though the original version only supported one user. We 
believe that a properly designed interactive system is much more productive and 
satisfying to use than a ``batch'' system. Moreover, such a system is rather 
easily adaptable to noninteractive use, while the converse is not true. </P>
<P>Second: there have always been fairly severe size constraints on the system 
and its software. Given the partially antagonistic desires for reasonable 
efficiency and expressive power, the size constraint has encouraged not only 
economy, but also a certain elegance of design. This may be a thinly disguised 
version of the ``salvation through suffering'' philosophy, but in our case it 
worked. </P>
<P>Third: nearly from the start, the system was able to, and did, maintain 
itself. This fact is more important than it might seem. If designers of a system 
are forced to use that system, they quickly become aware of its functional and 
superficial deficiencies and are strongly motivated to correct them before it is 
too late. Because all source programs were always available and easily modified 
on-line, we were willing to revise and rewrite the system and its software when 
new ideas were invented, discovered, or suggested by others. </P>
<P>The aspects of Unix discussed in this paper exhibit clearly at least the 
first two of these design considerations. The interface to the file system, for 
example, is extremely convenient from a programming standpoint. The lowest 
possible interface level is designed to eliminate distinctions between the 
various devices and files and between direct and sequential access. No large 
``access method'' routines are required to insulate the programmer from the 
system calls; in fact, all user programs either call the system directly or use 
a small library program, less than a page long, that buffers a number of 
characters and reads or writes them all at once. </P>
<P>Another important aspect of programming convenience is that there are no 
``control blocks'' with a complicated structure partially maintained by and 
depended on by the file system or other system calls. Generally speaking, the 
contents of a program's address space are the property of the program, and we 
have tried to avoid placing restrictions on the data structures within that 
address space. </P>
<P>Given the requirement that all programs should be usable with any file or 
device as input or output, it is also desirable to push device-dependent 
considerations into the operating system itself. The only alternatives seem to 
be to load, with all programs, routines for dealing with each device, which is 
expensive in space, or to depend on some means of dynamically linking to the 
routine appropriate to each device when it is actually needed, which is 
expensive either in overhead or in hardware. </P>
<P>Likewise, the process-control scheme and the command interface have proved 
both convenient and efficient. Because the shell operates as an ordinary, 
swappable user program, it consumes no ``wired-down'' space in the system 
proper, and it may be made as powerful as desired at little cost. In particular, 
given the framework in which the shell executes as a process that spawns other 
processes to perform commands, the notions of I/O redirection, background 
processes, command files, and user-selectable system interfaces all become 
essentially trivial to implement. </P>
<H4>Influences </H4>
<P>The success of Unix lies not so much in new inventions but rather in the full 
exploitation of a carefully selected set of fertile ideas, and especially in 
showing that they can be keys to the implementation of a small yet powerful 
operating system. </P>
<P>The <I>fork</I> operation, essentially as we implemented it, was present in 
the GENIE time-sharing system [10]. On a number of points we were influenced by 
Multics, which suggested the particular form of the I/O system calls [11], and 
both the name of the shell and its general functions. The notion that the shell 
should create a process for each command was also suggested to us by the early 
design of Multics, although in that system it was later dropped for efficiency 
reasons. A similar scheme is used by TENEX [12]. </P>
<H4>IX. STATISTICS </H4>
<P>The following numbers are presented to suggest the scale of the Research Unix 
operation. Those of our users not involved in document preparation tend to use 
the system for program development, especially language work. There are few 
important ``applications'' programs. </P>
<P>Overall, we have today: </P>
<P><BR><BR><BR><IMG 
src="BSTJ version of C_ACM Unix paper.files/p6.2081990.gif"><BR><BR><BR>There is 
a ``background'' process that runs at the lowest possible priority; it is used 
to soak up any idle CPU time. It has been used to produce a million-digit 
approximation to the constant <I>e</I>, and other semi-infinite problems. Not 
counting this background work, we average daily: <BR><BR><BR><IMG 
src="BSTJ version of C_ACM Unix paper.files/p6.2081991.gif"><BR><BR><BR></P>
<H4>X. ACKNOWLEDGMENTS </H4>
<P>The contributors to Unix are, in the traditional but here especially apposite 
phrase, too numerous to mention. Certainly, collective salutes are due to our 
colleagues in the Computing Science Research Center. R. H. Canaday contributed 
much to the basic design of the file system. We are particularly appreciative of 
the inventiveness, thoughtful criticism, and constant support of R. Morris, M. 
D. McIlroy, and J. F. Ossanna. </P>
<H4>References </H4><BR><BR>
<DL compact>
  <DT>1.
  <DD>L. P. Deutsch and B. W. Lampson, `An online editor,' J. Comm. Assoc. Comp. 
  Mach. <B>10</B> 12, December 1967 pp. 793-799, 803 
  <DT>2.
  <DD>B. W. Kernighan and L. L. Cherry, `A System for Typesetting Mathematics,' 
  J. Comm. Assoc. Comp. Mach. <B>18,</B> pp. 151-157, March 1975. 
  <DT>3.
  <DD>B. W. Kernighan, M. E. Lesk and J. F. Ossanna, `Document Preparation,' 
  Bell Sys. Tech. J. <B>57</B> 6 part 2, pp. 2115-2135, July-August 1978. 
  <DT>4.
  <DD>T. A. Dolotta and J. R. Mashey, `An Introduction to the Programmer's 
  Workbench,' Proc. 2nd Int. Conf. on Software Engineering, October 13-15, 1976, 
  pp. 164-168. 
  <DT>5.
  <DD>T. A. Dolotta, R. C. Haight, and J. R. Mashey, `The Programmer's 
  Workbench,' Bell Sys. Tech. J. <B>57</B> 6, pp. 2177-2200, July-August, 1978. 
  <DT>6.
  <DD>H. Lycklama, `UNIX on a Microprocessor,' Bell Sys. Tech. J., <B>57</B> 6, 
  pp. 2087-2101. July-August 1978. 
  <DT>7.
  <DD>B. W. Kernighan and D. M. Ritchie, <I>The C Programming Language,</I> 
  Prentice-Hall, Englewood Cliffs, New Jersey, 1978. Second edition, 1988. 
  <DT>8.
  <DD>Aleph-null, `Computer Recreations,' Software Practice and Experience, 
  <B>1</B> 2, April-June 1971, pp. 201-204. 
  <DT>9.
  <DD>S. R. Bourne, `The UNIX Shell,' Bell Sys. Tech. J. <B>57</B> 6, pp. 
  1971-1990, July-August 1978. 
  <DT>10.
  <DD>L. P. Deutsch and B. W. Lampson, `SDS 930 time-sharing system preliminary 
  reference manual,' Doc. 30.10.10, Project GENIE, Univ. Cal. at Berkeley, April 
  1965. 
  <DT>11.
  <DD>R. J. Feiertag and E. I. Organick, `The Multics input-output system,' 
  Proc. Third Symposium on Operating Systems Principles, October 18-20, 1971, 
  pp. 35-41. 
  <DT>12.
  <DD>D. G. Bobrow, J. D. Burchfiel, D. L. Murphy, and R. S. Tomlinson, `TENEX, 
  a Paged Time Sharing System for the PDP-10,' Comm. Assoc. Comp. Mach., 
  <B>15</B> 3, March 1972, pp. 135-143. </DD></DL><BR><BR><A 
href="http://www.lucent.com/copyright.html">Copyright</A> &copy; 1996 Lucent 
Technologies Inc. All rights reserved. </BODY></HTML>