DennisM.RitchieBellLaboratories,MurrayHill,NJ,07974
注意:*本文首次发表于“LanguageDesignandProgrammingMethodologyconferenceatSydney,Australia,September1979”。会议记录作为讲稿出版于“ComputerScience#79:LanguageDesignandProgrammingMethodology,Springer-Verlag,1980”。这份稿件所基于的重印版本出现在“AT&TBellLaboratoriesTechnicalJournal63No.6Part2,October1984,pp.1577-93”。
在过去几年中，Unix操作系统已经得到广泛的使用，以至于它特别的名字已经成为Bell实验室的一个商标。它的重要特征已经被众人所知晓。自从1974[1]中所描述的那个首次发行之后，它经历了大量重写和修补，但是少有原则上更改。但是，Unix生于1969年而不是1974年，它的开发历程成了一个鲜为人知并可能有所教益的故事。本文提供系统演化的技术和社会环境的历史记录。
对于Bell实验室的计算机科学，1968-1969年这段时期有些动荡。主要原因是实验室缓慢的、但完全不可避免的、从Multics计划中撤出。对于整个实验室计算社区，问题是让Multics迅速交付某种可用的系统是日益明显的错误，更不用说最初幻想的那个万能系统了。在此期间，MurrayHill计算机中心还运行着一个昂贵的GE645机器来不适当的模拟GE635。在此期间发生的另一个剧变是计算服务和计算研究在组织上的分离。
出自Unix开始时主要涉及到小组(K.Thompson，Ritchie，M.D.McIlroy，J.F.Ossanna)的立场，Multics的倾覆有着直接感觉到的影响。在Bell实验室，我们是在Multics坚持实际工作的最后的人，所以我们仍寄希望于它的成功。更重要的是，Multics对整个社区承诺的方便的交互式计算服务对于我们这个有限的小组是事实上可以获得的，最初曾在CTSS系统下开发Multics，而后来是在Multics自身下。尽管Multics当时不能支持许多用户，它却能支持我们，尽管有高昂的花销。我们不想失去我们占据的舒适的小环境，因为不能获得类似的东西；甚至在GE操作系统下将在以后提供的分时服务都不存在。我们想要保留的不只是在其中编程的一个良好环境，还有可以围绕它组成团队的一个系统。我们获得的经验是公共计算的本质，如提供远程访问、分时机器，不只是在终端上键入程序来替代键盘穿孔机，还有鼓励密切交流。
实际上，回想起来这是非常明显的(并且当时也应该如此)，我们要求实验室花费大量的金钱在这么少的人身上去进行这么模糊的一个计划。此外，我非常确定那时操作系统对于我们的管理者不是支持工作的一个有吸引力的领域。他们正在进行的不仅是从开发操作系统的努力失败中解脱自身，还有免于运行本地的计算中心。所以我们建议的买一个机器，一方面可能导致又一个Multics，另一方面，如果我们生产了有用的东西，会导致他们需要负责又一个计算中心。
在1969年除了发生财务困扰之外，还做了技术性工作。在黑板上和潦草的笔记上，Thompson、R.H.Canaday和Ritchie开发了一个文件系统的基本设计，它后来成为Unix的心脏。多数设计出自Thompson，他是思考整个文件系统的推动力，但是我确信我贡献了设备文件的想法。Thompson对创建一个操作系统的渴望在这个时期经历了多种形式；他还写了(在Multics上)对草拟的文件系统设计和程序的分页行为的一个非常详细的模拟。此外，他开始在GE-645的一个新操作系统上工作，深入到为这个机器写一个汇编器和一个初步的内核，我所记得它的最大成绩是键入一个问候消息。这个机器是如此的复杂性以至于基本的消息已经是一个非常显著的成就了，但在明确了645在实验室的时日要用月来衡量的时候，这项工作被放弃了。
太空旅行，尽管它是一个非常吸引人的游戏，主要用来介入为PDP-7准备程序需要的笨拙的技术。不久Thompson开始实现以前设计的纸面文件系统(可能‘粉笔文件系统’更准确些)。没有办法实验的一个文件系统是没有结果的一个命题，所以他继续用工作操作系统的其他需要来充实它，特别是进程的概念。接着出现了一小组用户级别实用工具:复制、打印、删除和编辑文件，当然还有一个简单的命令解释器(shell)。直到这时所有的程序都使用GECOS写成并转移到PDP-7纸带上；而一旦汇编器完成了系统就可以支持自身了。直到1970年BrianKernighan推荐了这个名字‘Unix’，它是‘Multics’有些背叛的双关语，我们今天知道的这个操作系统就诞生了。
在结构上，PDP-7Unix的文件系统几乎同今天完全一样。它有：
重要的文件系统调用也在开始时就出现了。Read、write、open、creat(sic)、close:有一个非常重要的例外将在后面将讨论，他们都类似于今天你所见到的。一个次要的区别是I/O的单位是字而不是字节，因为PDP-7是一个字寻址的机器。在实践中仅意味着处理字符流的所有程序都要忽略null字符，因为null被用来把文件填充成偶数个字符。另一个次要的区别，偶尔讨厌的区别是终端缺乏字和行删除处理。终端实际上总是在原始模式下。只有一些程序(特别是shell和编辑器)费力的去实现删除处理。
尽管相当类似于目前的文件系统，PDP-7文件系统在一方面上有显著的不同:这里没有路径名字，给系统的每个文件名字参数都是相对于当前目录的简单的名字(没有‘/’)。在通常Unix意义上的连接不存在。与一组精心安排的约定一起，它们是使路径名的缺乏能够被接受的主要方式。
link调用有如下形式link(dir,file,newname)
所以每个用户不需要维护到所有感兴趣的目录的一个连接，有一个叫做dd的目录为每个用户包含一个目录条目。这样，要制作到在ken目录中x的文件的一个连接，我可以做lnddkenkenlnkenxxrmken
dd约定使chdir命令相对的方便了。它接受多个参数，并把当前目录依次切换成每个指名目录。所以chdirddken
这个文件系统实现的最严重的麻烦，除了缺乏路径名字之外，还有难于更改它的配置；如前所述，目录和特殊文件只能在磁盘建立的时候制作。安装一个新设备是非常痛苦的，因为设备的代码广泛的散布系统中；例如有依次访问每个设备的多个循环。不要惊讶，没有挂装可移动磁盘组件的想法，因为这个机器只有一个单一的fixed-head磁盘。
实现文件系统的操作系统代码是当前方案的彻底的简化版本。一个重要的简化来自系统不是多道程序(multi-programmed)的事实；内存中在一个时刻只有一个程序，并只在发生对换的时候在进程之间传递控制。所以，例如这里有一个iget例程使一个指名的i-node可获得，但它把这个i-node留在一个恒定的、静态的位置中，而不是返回到一个活跃i-node的大表的一个指针。存在着当前的缓冲机制的祖先(有大约4个缓冲区)，但本质上没有磁盘I/O和计算的重叠。这不只是为了简化而避免的。附加在PDP-7上的磁盘在那时是很快的；它每2微秒传输一个18-位字。另一方面，PDP-7自身有一个1微秒的内存周期节拍，并且多数指令占用2个周期(一个用于指令自身，一个用于操作数)。但是，间接寻址指令要求3个周期，并且间接寻址是很常用的，原因是这个机器没有变址寄存器。最后，DMA控制器不能在指令运行期间访问内存。结果是，如果在磁盘传输期间执行了任何间接寻址的指令，则磁盘就会招致溢出丢失(overrun)。这样在磁盘正在运行的时候，控制不能返回给用户，事实上也不能执行一般的系统代码。时钟和终端的中断例程，它们需要在所有时候都是可运行的，必须以非常奇怪的方式编码来避免间接寻址。
对于‘进程控制’，我解释为进程建立和使用的机制；今天的系统调用fork、exec、wait和exit实现了这些机制。不象文件系统，它基本上在最近的时候就存在，进程控制方案在PDP-7Unix已经使用之后经历了显著的突变。(在PDP-11系统中路径名的介入的确是一个可观的表示法改进，但不是基本结构上的改变。)
今天，shell执行命令的方式可以总结如下:
进程(独立执行的实体)存在于非常早期的PDP-7Unix中。事实上正好有两个，附属于这个机器的两个终端一人一个。这里没有fork、wait或exec。这里有exit，但是它的意思是非常不同的，一会就能见到。shell的主循环按下面这样运行。
关于这个原始实现的最有趣的事情是它预示(anticipate)了后来这个主题充分开发的程度。真的，它不支持后台进程，也不支持shell命令文件(更不用说管道和过滤器)；但是IO重定向(通过‘<’和‘>’)不久就有了；下面会讨论它。重定向的实现非常直接；在上面步骤3)shell只是把它的标准输入或输出替代为适当的文件。对后续开发最至关紧要的是把shell实现为存储在一个文件中的一个用户级别程序，而不是操作系统的一部分。
这个进程控制方案的结构，是每个终端一个进程，类似于许多交互式系统，例如CTSS、Multics、HoneywellTSS和IBMTSS及TSO。一般的这种系统要求特殊的机制来实现有用的设施，比如分开的计算和命令文件；Unix在这个发展阶段不费心去提供这种特殊机制。它还展示了一些恼人的、特殊性质的问题。例如，一个新近重建的shell必须关闭所有它打开的文件，除去刚才执行的命令所有打开的文件，废除以前的IO重定向。接着它必须重新打开对应于它的终端的特殊文件，来读取一个新命令行。没有/dev目录(因为没有目录名字)；此外，shell不能跨越命令保留任何记忆，因为在每个命令之后它都被重新再次执行。这样需要一个进一步的文件系统约定:每个目录都必须为对应于打开它的进程的终端包含一个tty条目。如果你意外的进入缺失这条目的一个目录，shell将无望的循环；唯一的补救就是重新启动。(有时缺失连接可能是其他终端造成的。)
现代形式的进程控制是在几天之内设计并实现的。令人惊异的是它如此容易的适合现存系统；同时也很容易看出来，设计的某些稍微不同寻常的特征恰好出现，是因为它们体现了对现存的东西做简单的、易于编码的变更。一个好的例子是fork和exec功能的独立。建立新进程的最通用的模型涉及指定一个程序让这个进程来执行；在Unix中，一个复制的(forked)进程继续运行同它的父亲一样的程序直到它进行一次明确的exec。这种功能的独立的确不是Unix独一无二的，并且实际上它是在Berkeley分时系统[2]中出现的，Thompson很熟悉它。尽管如此，它存在于Unix中最合理的原因主要是可以容易的实现fork而不用很多其他东西。系统已经处理多个(这时是两个)进程；有一个进程表，并且进程在主存和磁盘之间对换。fork的最初实现只要求
事实上，PDP-7的fork调用需要正好27行汇编代码。当然，需要操作系统和用户程序的一些其他变更，并且其中一些是非常有趣和意外的。此外组合的fork-exec相当的复杂，好像是因为exec同样的不存在；shell使用明显的IO已经完成了它的功能。
exit系统调用,它以前是读入shell的一个新拷贝(实际上是一种自动的没有参数的exec)，相当的简单；在新版本中进程只需要清除它的进程表条目，并放弃控制。
奇怪的是，变成wait的原语比当前方案更加一般化。一对原语在指名的进程之间发送一个字的消息:smes(pid,message)(pid,message)=rmes()
消息设施使用如下:父shell，在建立一个进程去执行一个命令之后，通过smes发送一个消息到这个新进程；在这命令终止的时候(假定它不尝试读任何消息)，这个shell的阻塞的smes调用返回一个错误指示目标进程不存在。所以shell的smes在效果上等价于wait.
一个不同的协议，它更多的利用了消息提供的通用性，是在初始化程序和每个终端的shell之间使用的。初始化进程，它的ID被当作是1，为每个终端建立一个shell，并接着发起rmes；每个shell，在它读到它的输入文件的尽头的时候，使用smes来发送一个常规的‘Iamterminating’消息到初始化进程，它为这些终端重建一个新的shell进程。
我不能想起消息的其他用途。这解释了为什么这个设施被当前系统的wait调用所替代，少了通用性，但更直接的适用于想要的目的。还可能与这个机制中明显的缺陷有关:如果一个命令进程尝试使用消息来与其他进程通信，它将破坏shell的同步。shell依赖发送用不被接收的消息；如果一个命令执行了rmes，它将收到shell的假冒消息，并导致shell读另一行输入，如同这个命令已经终止了一样。如果证明需要通用性的消息，则这个缺陷可能已经被修补好了。
在某种程度上，新的进程控制方案立即呈现出某些非常有价值的、但对实现不重要的特征；例如分离的进程(使用‘&’)和递归的把shell作为命令使用。多数系统必须为文件提供某种特定的‘批作业子任务’设施和特定的一个命令解释器以区别于交互使用的命令解释器。
尽管多进程的想法确实非常容易的就介入(slippedin)了，但有些后果是未预期到的。其中最难忘的是在新系统提出并显然的工作了之后不久就变得明显了。在我们庆祝的时候，发现chdir(改变当前目录)命令停止了工作。关于增补的fork如何破坏chdir调用做了大量的代码阅读和观念的反省。最终真相揭晓了:在老系统中chdir是一个普通命令；它调整附属在这终端上的进程的(唯一的)进程的当前目录。在新系统中，chdir命令正确的改变了为执行它而建立的进程的目录，但是这个进程迅速就终止了并对它的父shell没有任何影响!必须使chdir成为一个特殊命令，在shell内部执行。找出了许多命令式的功能有同样的性质，例如login。
并被如下执行:
shcomfile>output
事件序列是
这个问题的解决要求建立一个新的系统表来持有打开文件的IO指针，独立于打开它们的进程。
使用‘>’和‘<’字符的、非常方便的IO重定向符号在最早的PDP-7Unix系统中不存在，但是它确实出现的很早。象Unix的多数其他部分，它的灵感来自Multics的思想。Multics有非常通用的IO重定向机制[3]，具体为命名IO流，它可以被动态重定向到各种设备、文件、甚至通过特殊的流处理模块。甚至在我们十年前熟悉的Multics版本中，就存在一个命令把后续的正常预定到终端的输出切换文件上，和另一个命令来把输出重新附属到终端上。在Unix下可以写ls>xx
来得到在xx中的你的文件的一个列表，在Multics上表示为
iocallattachuser_outputfilexxlistiocallattachuser_outputsynuser_i/o
夏天结束的时候处理器到来了，但PDP-11是个新产品以至于直到12月还没获得磁盘。在此期间，在PDP-7上使用交叉编译器写了一个根本的、只在内存的Unix。多数时候，这个机器呆在角落里，做三个月的作业列举在6×8棋盘上所有闭合的跳马巡回。
一旦磁盘到来，系统迅速的完成了。在内部结构中，PDP-11Unix的第一个版本只体现了比PDP-7系统相对次要的改进；写它主要是大量转移工作。例如，没有多道程序；在任何时候在内存中只存在一个用户的程序。在另一方面，在到用户的界面上有重要的改变:出现了现在的目录结构，带有完整的路径名字,还有现代的形式exec和wait，和便利设施如终端的字符删除和行删除处理。可能对企业最有趣的事情是它的小尺寸:有24K字节的内存(16K给系统，8K给用户)，和有1K块(512K字节)的一个磁盘。文件限制到64K字节。
在定了PDP-11的订单的时候，好像是很自然的，或者是权宜之计，承诺了专注于字处理的一个系统。在硬件推延到来期间，PDP-7Unix日益增长的使用证明建立PDP-11Unix作为开发工具是正确的，适合在写一个更加专用的系统时使用。到了1971年春天，普遍的认同了没有人会对零碎的Unix有一点兴趣。所以，我们把roff文本格式化器转移到了PDP-11汇编语言，起步于从McIlroy在Multics上的BCPL版本转移来的PDP-7版本，它受到J.Saltzer在CTSS上的runoff程序的影响。在初夏，编辑器和格式化器到手了，我们准备好履行我们的契约为专利部准备专利应用提供文本处理服务。当时，他们正在为了这个目的评估一个商用系统；我们提供的主要优势(除了参与一个内部实验的疑点之外)有两点:首先，我们支持Teletype的model37终端，它带有一个扩展的活字箱，可以打印他们需要的多数数学符号；其次，我们迅速的赋予roff生成行编号页面的能力，这是专利办公室需要的而其他系统不能处理的。
在1971年的后半段，我们支持专利部的三个打字员，他们整天繁忙的打字、编辑并格式化专利应用，同时我们尝试完成自己的工作。Unix获得了在适度的硬件上提供有价值的服务的声誉，并且这个时期可能在利益/设备比率上标记了一个顶点；在没有内存保护并只有一个单一的.5MB磁盘的一个机器上，每个新程序的测试都需要细心和大胆，因为这可能轻易的使系统崩溃，打字员的几个小时的工作都意味着把更多信息推出到DECtape上，原因是磁盘非常小。
实验在尝试但很成功。不仅是专利部接受了Unix，并成为在实验室中众多小组中第一个认可我们工作的，而且我们得到了充分的信任度，说服我们的主管去获得第一个PDP11/45系统。我们从此集聚了很多硬件，并持续的致力于软件，但因为多数有价值的工作已经发表了，(例如在系统自身[1,5,6,7,8,9])，这里没有必要重复。
Unix对操作系统和命令语言文化的最受称赞的贡献就是管道，用在命令的管道线中。当然，基本想法决不是新的；管道只是协同例程(coroutine)的一种特殊形式。甚至实现都不是空前的，尽管我们当时不知道它；Dartmouth的分时系统[10]的‘通信文件’与Unix管道非常类似，但他们好像没有这么完整的开发使用。
管道在1972年出现于Unix，正好在系统的PDP-11版本运转之后，来自M.D.McIlroy的建议(或者是坚决主张)，它是以协同例程为特征的非层次控制流的的长期倡导者。在管道实现的很多年前，他就建议命令应当被当作二元操作符来考虑，它的左右操作数指定输入和输出文件。这样一个‘copy’实用工具将是如下的命令inputfilecopyoutputfile
要做一个管道线，命令操作符可以堆叠起来。这样，要排序input，整齐的标页数，并离线打印结果，你可以写
inputsortpaginateoffprint
sortinput|pr|opr
新设施被狂热的认可了，并且术语‘过滤器’马上就出现了。更改了许多命令来在管道线中使用。例如，没有人能想象到有人需要sort或pr实用工具在没有给出明显的参数的时候排序或打印它的标准输入。
不久这个表示法的一些问题就变得明显了。最讨厌的是一个愚蠢的词法问题:在‘>’之后的字符串是用空白来界定的，所以要在例子中给pr一个参数，你必须引用:
sortinput>"pr-2">opr>
opr
pr<"sortinput"<>opr>
我在上面的IO重定向章节提及到Multics提供一种机制，IO流可以定向通过处理模块，在去到(或来自)设备或文件的路途上作为发起者或接受者。因此好像Multics中的流接合是Unix管道的直接先驱，如同MulticsIO重定向的确是Unix版本的先驱。事实上我不认为这是真的，或者只在微弱的意义上是真的。不仅协同例程已经是众所周知的，而且他们的具体化为Multics可接合的IO模块要求特殊的编码，以至于不能用于其它任何目的。Unix管道线的天才之处恰好是它用经常以单一的方式使用的命令构造出来的。需要看到这个可能性并发明这个表示法的精神飞跃是真正巨大的。
在PDP-11到来的时候，B几乎立即就转移到它上面了。实际上，多精度‘桌面计算器’程序dc的一个版本是最先在PDP-11上运行的程序之一，恰好在磁盘到来之前。但是，B没有立即接管下来。只有短暂的想法用B重写操作系统而不是汇编器，对于多数实用工具也是同样的。甚至汇编器都用汇编语言重写。采用这个途径主要是因为解释性代码的缓慢。更小但仍在实际上很重要的是面向字的B语言和字节寻址的PDP-11之间的不匹配。
所以，在1971年，开始做的工作了变成了C语言[14]。从BCPL到B到C的语言开发的故事在别的地方[15]讲述了，不需要在这里重复。可能最重要的分水岭出现在1973年期间，这时操作系统内核用C重写了。在这个转折点上系统呈现了它的现代形式；最深远的改变是引入了多道程序。还有一些外在可见的改变，此外系统的内部结构变得更加合理和全面。这些努力的成功使我们确信C是给系统编程的一个几乎通用的工具，而不只是给简单应用的玩具。
今天，仍用汇编写的唯一重要的Unix程序就是汇编器自身；事实上所有的实用工具程序是用C写的，多数应用程序也是如此，尽管这是Fortran、Pascal、和Algol68等的领地。毫无疑问，Unix的成功多数来自可读性，可修改性，和它的软件的可移植性，而这都来自它们的用高级语言表达。
关于陈年回忆的令人欣慰的事情之一就是他们倾向于呈现出玫瑰色的光芒。当在这里描述的时候，Unix的早期版本所提供的编程环境好像是非常粗糙和原始的。我确信如果强行回到PDP-7我将发现它难以忍受的限制和缺乏方便的工具。然而，在当时好像不是这样；记忆决定了什么是好的和什么是持久的，和帮助创造使生命更美好的改进的乐趣。十年后，我希望我们回头看看，依然有同样的进步和连续结合在一起的混和感觉。
我要感谢S.P.Morgan、K.Thompson和M.D.McIlroy提供了早期的文档并挖掘了记忆。
因为我对描述想法的演化最有兴趣，本文只在非常重要的地方把想法和工作归属于个人。读者一般来说不应有所误解，这里不明确的指代词‘我们’指的是‘Thompson和做一些协助的我’。