man UNIX痛恨者手册

applelinux

UNIX痛恨者手册
第一章 UNIX——世界上第一个电脑病毒

“伯克利的两项最著名的产品是UNIX和LSD (一种毒品)，我想这不是巧合”

病毒依赖于微小的个体和强大的适应性得以生存。它们并不复杂：它们没有为呼吸，新
陈代谢，肌体活动等功能提供什么，只有足够的DNA或RNA以供繁衍。比如，肺炎病毒比
起它们入侵的细胞要小得多，但它们在每个肺炎流行季节都能够产生新的变种，造成无
数人死亡。

一个好病毒的特点是：

* 个头小
病毒做的事情不多，所以不需要很大。有人认为病毒不是生物，只是一些有破坏性的酸
和蛋白质。

* 可移植性
病毒经常变异，以便以不同的方式攻击不同的细胞。据说AIDS就是由猴子身上的病毒变
异而成的。

* 耗尽寄主的资源

* 快速变异

UNIX具有以上所有优点。在它刚诞生时，很小，功能不多，缺乏真正操作系统所需要的
功能（如文件映射，告诉IO，健壮的文件系统，设备锁，合理的进程间通讯），它的移
植性很好。UNIX耗尽主机的资源，没有系统管理员的时时呵护，UNIX会不断恐慌，core
dump，挂起。UNIX不断变异：同一个补丁在一个版本上工作，在另一个版本上就不行。


UNIX是有用户界面的计算机病毒。


标准化那些不一致的
================

“标准的伟大之处在于它可以有很多” --- Grace Murray Hopper

自从UNIX 80年代开始流行以来，UNIX厂商一直在努力进行UNIX标准化工作。SUN, IBM，
HP和DEC在这个他们自己制造的难题上倾注了数百万美元。

为什么UNIX厂商不喜欢UNIX标准化?

许多用户受够了复杂繁多的UNIX，最终只好使用Windows，因为他们的这个UNIX无法支持
那个UNIX上的应用程序。

如果UNIX标准化了，谁还会买SUN的机器呢
第二章 欢迎新用户

欢迎新用户如同用一把上了六颗子弹的左轮枪玩俄罗斯轮盘赌

Ken Thompson 自己设计过一辆汽车。和其他车不同，它没有速度计、汽油计，也没有那
些愚蠢的指示灯讨司机的厌。如果司机犯了什么错误，仪表盘上就会出现一个大大的“
？”。“有经验的司机，”Thompson说，“应该知道哪儿搞错了。”

计算机系统的新手需要一个友好的系统。至少，一个得体的系统会这样招待自己的客人
：


与功能有逻辑关系的命令名
对危险命令的小心处理
一致的命令行为和命令行参数解析
易得和易读的在线文档
当命令失败时，给出可理解和有用的错误反馈


在建造UNIX的过程中，从没邀请过住户。来访的都是些戴着安全帽的建筑工人，被安插
在这个破木板房子的各个角落。不幸的是，不仅没有人性因素（human factors）工程师
的参与，而且住户的需要就从来没有被考虑过。所以抽水马桶、中央供暖、窗户等这些
方便设施在后期就很难再添加了。但是建筑师们仍然为UNIX的设计而骄傲，似乎他们并
不介意在一个没有烟火探测器的屋子里睡觉。

在其发展的大部分历史中，UNIX只是大学和工业研究人员的研究工具。随着大批便宜工
作站的出现，UNIX作为平台软件进入了新时代。这一变化大约发生在1990年，其标志就
是工作站厂商把C编译器从UNIX发布中剔除出去，以降低成本满足非开发用户的需求。可
见，只是最近几年中UNIX厂商才开始考虑非程序员用户的需要，开始为他们提供shell以
外的图形界面。

含糊的命令名

UNIX新手总是对UNIX对命令的命名表示惊讶。在DOS和Mac上受的教育不足以让他们体会
到cp、rm、ls这类两字母命令的简洁和优美。

像我们这样用过70年代早期的IO设备的人都能理解，ASR-33 Teletype这类设备的速度、
可靠性，以及它的键盘是万恶之源。和今天这种基于反馈原理、只需要关闭一个微开关
的键盘不同，你必须用足力气揿下Teletype的键至少半英寸，以发动一个类似自行车上
用的小型发电机，在上面操作要冒指骨骨折的危险。

如果当时Dennis和Ken用的是Selectric而不是Teletype，可能今天我们敲的将不是”cp
”和”rm”而是”copy”和”remove”了。（Ken Thompson曾被问道如果他能重新设计U
NIX他将做什么修改，他回答说：“我会在creat命令后加上个e。”），科技在拓宽我们
的选择的同时，也能限制我们的选择，此一例也。

20多年过去了，还有什么理由延续这一传统呢？理由就是“历史的无可替代的力量”，
历史就是那些存在的代码和教科书。如果一个厂商用remove替代了rm，那么所有UNIX教
科书就不适用于这一系统了，每个使用rm的shell脚本都需要被修改。而且这也不合POSI
X标准。

一个世纪前，打字高手由于击键过快，经常把打字键柄搅在一起，工程师设计了QWERTY
键盘，于是问题得到了解决，因为没人能在这样的键盘上打得快。计算机的键盘不再有
机械键柄，但QWERTY的键盘布局仍然在使用。同理，在未来的一个世纪中，我们仍然会
继续使用rm。

事故会发生

用户十分关心自己的数据和文件。他们使用计算机来产生、分析和存储重要信息。他们
相信计算机能够保护他们的重要财产。如果没有了这种信任，他们和计算机的关系就会
蒙上阴影。UNIX辜负了我们的信任，它拒绝对使用危险命令的用户提供保护。比如rm就
是以删除文件为目的的危险命令。

所有UNIX新手都有不小心无可挽回地删除重要文件的经历，即使是专家和系统管理员也
遇到过。因此而每年损失的时间、精力可能价值几百万美元。这是个值得解决的问题；
我们不理解为何UNIX一直拒绝解决这一问题。难道结果还不够悲惨么？

UNIX比其他操作系统更需要提供恢复删除功能，原因是:

UNIX文件系统没有版本功能
自动的版本维护能保留文件的历史版本，防止新版本冲掉老版本。
UNIX程序员在错误处理方面臭名昭著
许多程序不检查是否所有内容都被写入了磁盘，或被写入的文件是否存在。有些程序总
是删除输入文件。
UNIX shell扩展“*”，而不是其子命令
于是rm这样的命令就无法检查“*”这些危险的参数。即使是DOS也对”del *.*”有些提
示。但在UNIX下，rm * 和 rm file1 file2…是没有区别的。
删除是永久的
UNIX没有undelete命令。许多其他更安全的系统则只是标记被删除文件所用的块为“可
被使用”，然后把它移到一个特殊目录下。如果磁盘满了，这些文件块才会被重新使用
。这一技术不是什么火箭科学，Macintosh在1984年就提出了“回收站”的想法，而Tene
x早在1974年就采用了这一技术。连DOS也提供了简单的undelete功能，虽然并不总有效
。


这四个问题互相合作，制造了无数无法恢复的重要文件。解决的方法早就存在，但UNIX
“标准”版中却从来没有提供。

欢迎来到未来世界。

“rm”就是终结

许多实际的恐怖故事说明了以上的这些原则。以下是alt.folklore.computers新闻组上
流传的一系列故事中的一个：


Date: Wed, 10 Jan 90
X-Virus: 6
From: [email protected] (Dave Jones)
Subject: rm *
Newsgroups: alt.folklore.computers

是否有人曾想执行以下命令:
% rm *.o
结果却打成了：
% rm *>o
现在你得到了一个空文件o，以及大量的空间来存放它！


事实上，你可能连o也得不到，因为shell的文档并没有说o是在*被扩展前还是被扩展后
被建立的。

上回书说到如何用rm获得一个空文件和很大的磁盘空间，下面是另一种用法：


Date: Wed, 10 Jan 90
X-Virus: 6
From: [email protected]
Subject: Re: rm *
Newsgroups: alt.folklore.computers

我也被rm搞过。有一次我想删除一些/usr/foo/下的东西，我在/usr/foo下敲了以下命令
：
% rm –r ./etc
% rm –r ./adm
当我要删除./bin目录时，我忘敲了那个点。我的系统似乎不太喜欢这个。


当受了这一致命一击后，UNIX就彻底完蛋了。聪明的系统会给用户一个恢复的机会（或
至少提醒用户这一操作会导致系统崩溃）。

UNIX迷认为偶尔的文件误删除是正常的。比如，可以参考以下下面这个comp.unix.quest
ions上的FAQ:


6) 如何反删除一个文件？

也许有一天，你不小心执行了一下这个命令：
% rm * .foo
然后发现你把“*”删掉了。你应该把这当作人生的一课。
当然称职的系统管理员应该定时备份系统。所以你最好问问他们手中是不是有你的文件
备份。


“人生的一课”？没有任何一个其他厂商用这样的态度对待一个有缺陷的产品。“大人
，我知道您的油箱炸了，但这是人生的一课。”“陪审团的先生女士们，我们将证明电
锯保险开关的失效不过是给用户上的人生的一课。”不错。

改变rm的行为也不是个办法

被rm咬了几次后，往往会想到用”rm -i”替换rm，或整个替换掉rm，把所有被删除的文
件放到~/.deleted目录中。这些小技巧让用户有了错误的安全感。


Date: Mon，16 Apr 90 18:46:33 199
X-Virus: 6
From: Phil Agre <[email protected]>
To: UNIX-HATERS
Subject: deletion

在我们的系统上，”rm”并不真正删除文件，而是给文件换了名，这样”undelete”(不
是unrm)这样的工具就能恢复被删的文件。

这个功能让我不再对删除文件多加小心，反正删掉了也能找回来。可是，我错了。Emacs
中的删除并不支持这个功能，Dired命令也是如此。这当然是因为文件恢复并不是操作系
统的一个功能。

所以，现在我脑子里有两个概念，一个是”deleting”一个文件，一个是”rm’ing”一
个文件。当我的手要我的脑子删除一个文件时，我总要把这两个概念区分一遍。


一些UNIX专家由此得出了荒谬的结论，他们认为最好别把rm搞得更友好。他们争辩说，
让UNIX更友好的努力往往适得其反。不幸的是，他们是对的。


Date: Thu, 11 Jan 90 17:17 CST
X-Virus: 6
From: [email protected] (Randal L. Schwartz)
Subject: Don’t Overload commands! (was Re: rm *)
Newsgroups: alt.folklore.computers

请千万别让人用“安全”命令去替换标准命令。
（1） 许多shell程序会对多嘴的rm感到惊讶，而且也不会想到删除了的文件仍然占有磁
盘空间。
（2） 并不是所有删除操作都是安全的，有户会因此产生一切都能恢复的错觉。
（3） 那些不标准的命令对系统管理员来说尤其可恨。
如果你想有个有确认功能的”rm”，用下面的命令:
% alias del rm -i
千万别替换rm!


最近，comp.unix.questions上有过一次对系统管理员的调查，让他们说出最恐怖的系统
管理故事。72小时内，就有了300多条回应。许多和我们上面描述的文件删除有关。可笑
的是，这些可是UNIX高手。然而正是他们在对“UNIX对用户不友好”这类指责进行着辩
护。

对用户不友好？UNIX对系统管理员又友好过么？请看


Date: Wed, 14 Sep 88 01:39 EDT
X-Virus: 6
From: Matthew P Wiener <[email protected]>
To: [email protected]
Subject: “Single Keystroke”

在UNIX上，即使是有经验的用户也会误用rm。我从来没有误删除过文件，可是有一天，
我用!r重复执行一个历史命令，我惊讶地发现被运行的是”rm –r *”。

为什么不能有个没有history功能的shell?

我还听到过一个用户试图删除一个名叫”*”的文件，好在他没有权限。


这个用户还想修改shell来避免对*进行展开。不幸的是，这个补救如同是在渗水的墙上
再刷一层漆，治标不治本。

在线帮助

用户读打印文档的次数比他们参加选举投票的次数还要少。只有触手可及的在线文档才
是有用的。下面我们看看UNIX的man是如何让最需要它的新用户失望的。

不是每个命令都是平等的，有些是外部命令，有些是内部命令。有些有man page，有些
没有。UNIX要求你能区分这些命令。比如，wc, cp和ls是外部命令，它们都有man page
，而fg, jobs, set和alias（这些长文件名是从哪里来的？）是内部命令，它们没有man
page。

UNIX告诉新手用”man command”命令获得帮助，他们可不知道并不是所有命令都是如此
。另外，如果他们的shell设置得有些不标准，他们就只能请教高手来获得帮助了。

错误信息和错误检查？没门!

新手很容易犯错误，比如用错命令，或用错选项。系统应该能识别这些错误，并且反馈
给用户。不幸的是，UNIX程序从来不麻烦自己。相反，UNIX往往把各种错误混在一起，
直到产生致命的结果。

上面一节我们说明了rm如何容易造成误删除。但你可能不知道不用rm也能很容易地误删
除文件。

想删除你的文件么？试试编译器

一些cc版本经常根本不考虑用户的可能输入错误，而删除一些源代码文件。一些本科生
常常着了道。


Date: Thu, 26 Nov 1992 16:01:55 GMT
X-Virus: 6
From: [email protected] (Tommy Kelly)
Subject: HELP!
Newsgroups: cs.questions
Organization: Lab for the Foundations of Computer Science, Edinburgh UK

我刚才想这么编译程序：
% cc –o doit doit.c
不小心敲成了：
% cc –o doit.c doit
不用说我的doit.c被冲掉了。有没有办法能恢复我的程序？（我干了整整一个上午）


其他一些程序也有同样的行为:


Date: Thu, 1 July 1993 09:10:50 - 0700
X-Virus: 6
From: Daniel Weise <[email protected]>
To: UNIX-HATERS
Subject: tarred and feathered

经过几次努力，我总算从欧洲的一个脆弱ftp站点上下载了了一个3.2M的文件。该untar
它了。我敲了一下命令:
% tar –cf thesis.tar
…没有回应。

老天！

是不是该用x选项而不是c?
是的。

tar是不是给出了错误信息说没有指定输入文件？
没有。

tar是否感觉到有什么不对劲？
没有。

tar是不是真的什么也没有tar?
是的。

tar是否把thesis.tar用垃圾覆盖了？
当然，这就是UNIX。

我是不是需要再花 30分钟从欧洲下载这个文件？
当然，这就是UNIX。

我敢肯定有不少人遇到过这一不幸，有那么多的解决办法，比如：错误信息，文件版本
化，确认用户是否想覆盖一个已有文件，等等等等。tar似乎在有意给用户找麻烦。


对于经常用tar备份的系统管理员来说，这个bug更是危险。不少系统管理员都曾经在备
份脚本中错误地使用过“tar xf…”。在需要恢复备份的时候，才发现原来什么也没做
。

欲知是否还有其他这样的恐怖命令，请听下回分解。


上回书说到cc、tar等命令是如何帮助你删除重要文件的。UNIX的强大当然不局限于此。


因为没有错误检查，在众多“UNIX 强大编程工具”的支持下，用户有各种选择来删除他
们的重要文件。


Date: Sun, 4 Oct 1992 0:21:49 PDT
X-Virus: 6
From: Pavel Curtis <[email protected]>
To: UNIX-HATERS
Subject: So many bastards to choose from…

我有一个总在运行的程序foo，用来提供网络服务，并且每隔24小时检查系统内部状态。


一天，我cd到foo所在的目录，因为这不是开发目录，我想看看foo的版本是多少。代码
是由RCS来维护的，所以我自然而然地使用了以下命令:

% ident foo

先别管RCS的种种劣迹，也别管ident如何原始疯狂。我这次的麻烦是，我的手指自行其
是地选择了更像一个词的indent而不是ident:

% indent foo

indent是UNIX的一个愚蠢的C代码风格转换工具。那个写indent的混蛋是否判断了一下输
入文件真的为C程序么 (天哪，至少可以看看文件的后缀是否为.c吧)？我想你知道答案
。而且，这个SB(Said Bastard)认为如果你只给了一个参数，那么你就是想要进行在线
风格转换。不过别着急，这个SB 考虑到了可能带来的麻烦，他保存了一个备份foo.BAK
。然而他是否只是简单地把foo换了个名字呢？没有，他选择了拷贝(毫无疑问，那个写i
ndent的程序员在准备备份的时候已经打开了foo，而且rename系统调用是后来才有的)。
现在，你可能知道发生了些什么了…

我那正在运行中的foo在准备页面扇出的时候，发现原来的可执行文件已经不在了，这可
不是什么好事，于是我的foo崩溃了，我丢掉了20小时的系统状态信息。

自然那些设计（咳嗽）UNIX的混蛋们对复杂的文件版本化功能不感兴趣，而这一功能就
能救我的命。当然，那些混蛋也从未想到过对准备进行页面扇出的文件加锁，是不是？

有那么多混蛋可供选择，为什么不把他们都宰了？

Pavel

想象一种散发氯气的油漆，按照说明，用在户外是不成问题的，但如果用它刷你卧室的
墙壁，你的脑袋就要大了。这样的油漆能在市场上存活多久呢？当然不会超过20年。

错误信息笑话

当你看到饭馆跑堂的把一盘菜撒在顾客脑袋上时，你会笑么？UNIX迷会的。但那些无助
的用户对着错误信息百思不得其解的时候，他们是最先发出笑声的。

有人整理了一些UNIX最为可笑的错误信息，把他发布在Usenet上。他们使用的是C
shell.


% rm meese-ethics
rm: messe-ethics nonexistent

% ar m God
ar: God does not exist

% “How would you rate Dan Quayle’s incompetence?
Unmatched “.

% ^How did the sex change^ operation go?
Modifier failed.

% If I had a ( for every $ the Congress spent, what would I have?
Too many (‘s

% make love
Make: Don’t know how to make love. Stop.

% sleep with me
bad character

% got a light?
No match

% man: why did you get a divorce?
man: Too many arguments.

% ^What is saccharine?
Bad substitute.

% %blow
%blow: No such job.

下面的这些幽默作品来自Bourne Shell:


$ PATH=pretending! /usr/ucb/which sense
no sense in pretending

$ drink <bottle; opener
bottle: cannot open
opener: not found

$ mkdir matter; cat >matter
matter: cannot create


UNIX态度

我们展现了一个非常惨淡的图景: 迷一般的命令名，不一致和无法预计的运行结果，危
险命令没有保护，无法接受的在线文档以及在错误检查和容错性方面的稀松工作。那些
参观UNIX的人不是为了得到热情款待，他们不是迪斯尼公园中的游客，更像是执行任务
中的联合国维和部队。UNIX怎么会搞成这个样子？如我们曾指出的那样，其中有一些是
历史原因造成的。但是还有其他的原因：那就是多年来形成的UNIX文化，这种文化被称
为 “UNIX哲学”。

UNIX哲学不是来自Bell实验室或UNIX系统实验室的手册。他是自然形成的，其中包含了
许多人的贡献。Don Libes和Sandy Ressler在《UNIX生活》(Life with UNIX)中对UNIX
哲学作了很好的总结：


小即是美
用10%的工作解决90%的任务
如果必须作出选择，选择最简单的那个。


根据UNIX程序和工具的实际表现来看，对UNIX哲学更为精确的总结应该是:

小的程序比正确的程序更好
粗制滥造是可以接受的
如果必须作出选择，选择责任最小的那个。


UNIX没有哲学，UNIX只有态度。这个态度指出简单的做了一半的工作比复杂完整的工作
更好。这个态度指出程序员的时间比用户的时间更为珍贵，即使用户比程序员要多得多
。这个态度指出达到最低要求就足够了。


Date: Sun, 24 Dec 89 19:01:36 EST
X-Virus: 6
From: David Chapman <[email protected]>
To: UNIX-HATERS
Subject: killing jobs; the Unix Design Paradigm

我最近学会了如何在UNIX上杀掉任务。在这个过程中我体会到了不少UNIX的强大和智慧
，我想应该和大家分享一下。

你们中的大多数当然不用UNIX，所以知道如何UNIX上杀任务估计没什么用。但是，你们
中的一些人，包括我，可能会经常运行一些TeX任务，那么学会杀任务就显得尤为重要了
。“kill”命令继承了UNIX的设计原则，所以下面的一些体会有更为通用的意义。

在UNIX中你可以用^Z挂起一个任务，或者用^C终止一个任务。但是LaTex自己截获^C。结
果是，我经常搞出一堆LaTex任务。我对此到不在乎，可还是觉得应该想办法除掉它们。


许多操作系统有“kill”这样的命令，UNIX也不例外。大多数操作系统上的“kill”仅
仅用来杀死进程。但UNIX的设计更为通用：“kill”被用来向进程发送一个信号，这体
现了UNIX的一个设计原则：

尽量使操作通用，给予用户强大力量(power)


“kill”命令功能很是强大；你能用它给进程发送各种各样的信号。比如，9这个信号用
来杀死进程。注意到9是最大的一位数，这体现了UNIX的另一个设计原则：

使用能体现功能的最简单的名字


在其他我知道的操作系统上，不带参数的“kill”用于杀死当前任务。单UNIX的“kill
”总是需要参数。这体现了UNIX的一个明智的设计原则：

尽量使用长参数或提示来防止用户不小心把自己操了(screwing himself)


这一设计原则在许多UNIX应用程序中得到了体现，我不想列举它们，但还是想提一下UNI
X上logout和文件删除的实现，希望你知道我的意思。

在其他我知道的操作系统上，“kill”接受的参数是任务名。这不是好的选择，因为你
可能有许多LaTex任务同时运行，它们都有同样的任务名“latex”。所以“kill –9
latex”可能会产生歧义。

和其他操作系统一样，UNIX提供一个列出任务的命令“jobs”，下面是一个例子：

zvona@rice-chex> jobs
[1] – Stopped latex
[1] – Stopped latex
[1] + Stopped latex

这样你可以用job号（表示在[]中）标识一个任务。

如果你受到那些未经精雕细刻的操作系统的影响，你会想用“kill –9 1”来杀掉第一
个latex任务。但你会发现下面的错误信息：

zvona@rice-chex> kill -9 1
1: not owner

正确的做法是使用进程号，比如18517。你能用“ps”命令获得它。当找到了相应进程号
后，你只要：

zvona@rice-chex> kill -9 18517
zvona@rice-chex>
[1] Killed latex

注意到UNIX在你的任务被真正杀掉之前就给了你提示符。这又体现了一个UNIX设计原则
：

对于给用户的反馈，能少说绝不多说，能晚说绝不早说。以免过多信息所可能导致的用
户脑损伤。


我希望这些体会能对大家有用。在这一学习过程中，我自己当然被UNIX设计哲学所深深
吸引了。我们都应该从UNIX kill命令的雅致、强大和简洁中学到些东西。

第二章就这么完了,经历了这么多艰难困苦的你已经不是新手了,下回书将介绍UNIX之文
档,或者说UNIX之没有文档.
第三章 文档

OK，不是新手的你可能想进一步学习了解UNIX。不错，UNIX文档正是你需要的。

文档
什么文档

“使用UNIX进行操作系统教学的一个好处是，学生的书包能装下所有的UNIX源代码和文
档。”
—— John Lions， 新南威尔士大学，1976年在谈论UNIX版本6时说的一段话。

多年以来，有三个获得UNIX有关知识的简单途径:


阅读源代码
写一个自己的UNIX
给写UNIX的程序员打电话（或是发email）


和荷马史诗一样，UNIX被口头传诵着。如果不成为内核黑客，你就不可能是一个严肃的U
NIX用户——或者至少应该在身边有个触手可及的内核黑客。那个确实存在的文档——ma
n手册——不过是一些已经知道自己在做什么了的人所收集的一些备忘录。UNIX的文档是
这么简洁，你能在一下午读完它。

在线文档

man工具是UNIX文档系统的基础。man接受你输入的参数，找到相应的文档文件，把它输
出到nroff（还包括一些地球上没有其他地方使用的一些文本格式宏），最后结果被发送
到pg或more。

起先，这些零碎文档被叫做”man页”(man pages)，因为这些文档多为一页左右（多数
情况是少于一页）。

man对于那个时代是个不错的玩意，但那个时代早已一去不复返了。

多年来，man系统不断发展成熟。值得称赞的是，它并没有像UNIX的其他部分一样搞得代
码混乱程序难懂，可是它也没变得更有用。事实上，在过去的15年中，UNIX的文档系统
只有了两处改进:

catman. 程序员曾“惊喜地”发现除了nroff格式以外，他们还能存储处理过的文档文件
，这样文档调出的速度就更快了。 对于今天的快速处理器，catman似乎不那么需要了。
但是许多nroff处理过的文档文件仍然占据着用户的几兆磁盘空间。
makewhatis, apropos和key (最终构成了man –k功能)是一个对man手册进行索引的系统
，这样即使不知道程序的确切名字也能进行查询。


与此同时，电子出版的势头早已超过了man手册。使用今天的超文本系统你能用鼠标从一
篇文章跳到另一篇文章；与之相比，man手册仅仅在末尾提供”SEE ALSO”一节，让用户
自己再man下去。在线文档的索引功能又是如何呢？今天你可以买到CD-ROM上的牛津英语
词典，它对其中的每一个词都加了索引；可是man手册还是仅仅对命令名和描述行进行索
引。今天甚至连DOS都提供了有索引的超文本文档。可是man手册还是采用适合DEC打印终
端的80列66行的格式。

公平点说，有些厂商是在看不下去，提供了自己的超文本在线文档系统。在这些系统上
，man手册走到了进化的尽头，常常不是过时了，就是根本不存在。

“我知道它就在这里，可就是找不到”

对于今天还在使用man手册的人来说，最大的问题是告诉man你要的man手册就在那里。在
以前，查找man手册是很容易的：全都在/usr/man下头。后来man手册按章节分成了不同
的目录：/usr/man/man1, /usr/man/man2,/usr/man/man3等等。有的系统甚至把“本地
”man手册也放在/usr/man/man1下。

当AT&T发布系统V的时候，情况变得费解了。/usr/man/man1目录变成了/usr/man/c_man
，似乎字母比数字更好记。在有些系统上，/usr/man/man1变成了/usr/local/man。那些
销售UNIX应用程序的公司开始建立自己的man目录。

最终，伯克利修改了man程序使得它能对环境变量$MANPATH中指定的一系列目录进行查找
。这是个伟大的想法，只有一个小毛病：它不工作。(以下省略100字, 因为我太懒了，
内容也有些太过时了，Linux上的man还是不错的，除了无法获得shell内部命令的man手
册，当然，man bash是一个选择 -- me)。

这个就是内部文档？

一些大的UNIX工具也提供自己的文档。许多程序的在线文档是一行叫人费解的 “使用”
（usage）说明。下面是awk的“使用”说明:

% awk
awk: Usage: awk [-f source | ‘cmds’] [files]

是不是挺有用的？复杂一些的程序有着更深入的在线文档。不幸的是，它们有时候描述
的似乎不是你正在运行的程序。

Date: 3 Jan 89 16:26:25 EST (Tuesday)
X-Virus: 6
From: Reverend Heiny <[email protected]>
To: UNIX-HATERS
Subject: A conspiracy uncovered (阴谋被揭露了)

经过几个小时的专心研究，我得出了一个重要的结论：

UNIX是狗屎 (UNIX sucks)

现在，你可能觉得很惊讶，但这是事实。这项研究已经被遍布全球的研究人员所证实了
。

更为重要的是，这不仅仅是摊狗屎，而是又稀又粘的臭狗屎，是大写的臭狗屎。看看下
面这个例子，你就知道了：

toolsun% mail
Mail version SMI 4.0 Sat Apr 9 01:54:23 PDT 1988 Type ? for help
“/usr/spool/mail/chris”: 3 messages 3 new
>N 1 chris Thu Dec 22 15:49 19/643 editor saved “trash1”
N 2 chris Tue Jan 3 10:35 19/636 editor saved “trash1”
N 3 chris Tue Jan 3 10:35 19/656 editor saved “/tmp/ma9”
& ?
Unknown command: “?”
&

什么样的系统环境（特别是这个到了能开车、投票、喝啤酒年龄的家伙）会拒绝一个它
让使用的命令？

为什么用户手册是如此脱离现实？

为什么这些神秘的命令是这么和功能不符？


我们不知道Heiny的问题是什么；和我们上面提到的一些问题一样，这个bug似乎已经被
修正了。或者说，它被转移到了其他程序中。

Date: Tuesday, September 29, 1992 7:47PM
X-Virus: 6
From: Mark Lottor <[email protected]>
To: UNIX-HATERS
Subject: no comments needed (无需多说)

fs2# add_client
usage: add_client [options] clients
add_client -i | -p [options] clients
-i interactive mode – invoke full-screen mode

[还有一些选项，这里省略了]

fs2# add_client -i

Interactive mode uses no command line arguments


如何得到真正的文档

实际上，UNIX最好的文档是经常用strings处理程序二进制代码。使用strings你能得到
所有程序中定死了的文件名，环境变量，未公开的选项，怪异的错误信息等等。比如，
如果你想知道cpp是如何去查找头文件的，你最好使用strings而不是man:

next% man cpp
No manual entry for cpp.
next% strings /lib/cpp | grep /
/lib/cpp
/lib/
/usr/local/lib/
/cpp
next%

嗯…别着急

next% ls /lib
cpp* gcrt0.o libssy_s.a
cpp-precomp* i386/ m68k/
crt0.o libsys_p.a posixcrt0.o
next% strings /lib/cpp-precomp | grep /
/*%s*/
//%s
/usr/local/include
/NextDeveloper/Headers
/NextDeveloper/Headers/ansi
/NextDeveloper/Headers/bsd
/LocalDeveloper/Headers
/LocalDeveloper/Headers/ansi
/LocalDeveloper/Headers/bsd
/NextDeveloper/2.0CompatibleHeaders
%s/%s
/lib/%s/specs
next%

我真笨。NEXTSTEP的cpp使用了/lib/cpp-precomp。你不可能在man手册中发现这些。

next% man cpp-precomp
No manual entry for cpp-precomp.


OK. 这一切究竟是因为什么？这一切究竟是从何而来？下回分解。

上回书说到源代码是最好和唯一的文档，根本原因是因为UNIX是...

给程序员用的，不是用户

别因为UNIX蹩脚的文档而责怪Ken和Dennis。 UNIX刚开始建立文档时并没有遵守业界流
行的文档标准，一些bug和潜在的陷阱，而不是程序的功能，被记录了下来，这是因为读
这些文档的人往往就是UNIX系统开发者。对于许多开发者来说，man手册不过是收集bug
报告的地方。那些针对初级用户、程序员和系统管理员提供文档的观念是新玩意。可悲
的是，由于70年代建立的UNIX文档系统，这一观念实现的并不是很成功。

UNIX世界认识到了这些文档方面的现状，但并不觉得有什么大不了的。《UNIX生活》很
客观地说明了UNIX对于文档的态度:

UNIX源代码是最好的文档。毕竟，这是系统用以决定该如何运行时所参照的文档。文档
用来解释代码，经常是一些不同的人在不同的时间写成的，而这些人往往不是写代码的
人。你应该把这些文档看作是指南。有时候这些文档不过是些期望而已。

但是，更一般的做法是去源代码中寻找未被文档化使用方法和功能说明。有时候你会发
现一些文档中记录的功能其实并没有被实现。

这还只是针对用户程序。对于内核，情况就更为糟糕了。直到最近，还没有厂商提供的
设备驱动编写和内核级调用函数的文档资料。有人开玩笑说：“如果你觉得需要阅读关
于内核函数的文档，那么很可能你本来就不配使用这些函数。”

真相恐怕更为邪恶。之所以没有内核文档是因为AT&T把它的代码看成是商业机密。如果
你想写一本说明UNIX内核的书，那么你就等着入被告席吧。

源代码就是文档

命里注定，AT&T的计划弄巧成拙了。由于没有文档，了解内核和应用程序的唯一途径就
是阅读源代码。结果是，UNIX源代码在在最初的20年中被疯狂的盗版。咨询人员，程序
员和系统管理员去搞UNIX源代码并不是为了重新编译或制作出售自己的UNIX版本，他们
需要文档，而源代码是唯一的选择。UNIX源代码从大学流向周边的高科技公司。这当然
是非法的，但是情有可原：UNIX厂商提供的文档不够用。

这并不是说源代码中有什么值钱的秘密。所有读过UNIX代码的人都被下面的一行粗暴注
释惊呆过：

/* you are not expected to understand this */ （/* 没指望你能明白 */）

尽管这行注释最开始出现在UNIX V6内核中，但是几乎所有的原始AT&T代码都差不多，其
中充满了内联手动优化和怪异的宏。寄存器变量被冠以p, pp和ppp这类的名字。“这个
函数是递归的”这样的注释似乎表明递归调用是什么难理解的概念。事实上，AT&T在文
档方面好为人师的态度只不过是其写代码的马虎态度的一个反映。

要识别一个蹩脚手艺人其实很简单：你会看到裂缝上的油漆，一个接一个的补丁，所有
东西被胶带和口香糖勉强凑合在一块儿。必须承认：如果想从头建立和重新设计什么，
必须要多思考，多下功夫。

Date: Thu，17 May 90 14:43:28 -0700
X-Virus: 6
From: David Chapman <[email protected]>
To: UNIX-HATERS

这是man man中的一段，挺有意思：
DIAGNOSITICS
如果你使用-M选项而且给出的路径并不存在，那么输出的错误信息可能有点儿不对。比
如/usr/foo/目录不存在，如果你运行:

man –M /usr/foo ls

那么你得到的错误信息是“No manual entry for ls”（“没有ls的手册记录”）。正
确的错误信息时告诉你目录/usr/foo不存在。

有写这段说明的功夫，恐怕足够修改这个bug了。

无言UNIX：课程设置建议


Date: Fri, 24 Apr 92 12:58:28 PT
X-Virus: 6
From: [email protected] (C J Silverio)
Organization: SGI TechPubs
Newsgroups: talk.bizarre
Subject: UNIX Without Words (无言UNIX)

[在一场关于文档无用论的激烈辩论中，我提出了下面这个建议。我胆子小，所以现在才
敢公开，供大家参考。]

UNIX Ohne Worter (不会翻 – me)

我被这里散步的文档无用论观点深深折服了。事实上，我进一步认为文档就是毒品，我
对于它的依赖性是人为造成的。在专业人士的帮助下，我想我能够戒掉它。

而且，我的良心告诉我不能再靠贩卖这种毒品为生了。我决定回到数学研究院脱胎换骨
，彻底从这个寄生虫一样的职业中脱身。

虽然下面这份文档似乎表明了我中毒有多么深，可我还是觉得下一版SGI中应该把它提供
给用户。这不过是暂时之举，以后会把它搞掉的。

这是我的建议:

标题：“无言UNIX”

对象：UNIX新手

简介：提供在没有文档条件下使用UNIX的通用策略。展示在没有文档条件下摸清任何操
作系统的通用原则。

内容:

介绍：“无文档”哲学简介
为什么手册是恶魔
为什么man手册是恶魔
为什么你还是应该读这份文档
“这将是你读的最后一份文档！”
第一章：如何猜测可能存在哪些命令
第二章：如何猜测命令名

UNIX的怪异缩略命名法
案例：grep
第三章：如何猜测命令选项

如何破解怪异的使用说明
案例：tar
如何知道什么时候顺序是重要的
案例：fine
第四章：如何知道运行正确：没有消息就是好消息

从错误中恢复
第五章：口头传统：你的朋友
第六章：如何获得和维持一个活生生的UNIX高手

如何喂饱你的高手
如何让高手高兴
提供全部新闻组连接的重要性
为什么你的高手需要最快的计算机
免费可乐：高手的长生不老药
如何保持高手身体健康
高手什么时候睡觉?
第七章：常见疑难：你的高手不理你了

识别愚蠢的问题
如何安全地提出愚蠢问题
第八章：如何承受压力

如何对待失败

注：可能只有6、7章才是真正需要的。是的，这才是正路：我把它称为“UNIX高手驯养
指南”。


OK, 再也没有文档了。下回书将带你进入sendmail的美好世界，为什么“使用sendmail
的感觉和得了花柳病一样。”？下回分解。
第八章 csh, pipes和find (part 1)

UNIX演义又开始了，本来这回书要表一表sendmail和花柳病的关系，不过sendmail似乎
已经从良了，从良妓女比贞节烈女对我们民族的贡献要大得多，所以不想再找她麻烦了
，对妓女发展史和性病斗争史感兴趣的，我们可以私下交流。

作为程序员而不是妓女的你，可能对UNIX的编程环境更感兴趣，所以这一节中介绍一下U
NIX Shell的历史。我GPL，你没花钱，所以只能任我摆布，我上什么你就吃什么，不要
废话。

GPL的好处在于你不必为自己的工作负责，也不必对用户负责，所以sourseforge上充斥
着良莠不齐的自由项目。我希望我的心上人也能理解这一点，这一切的开始并不是为了
什么价值、责任、过去或是未来，这一切甚至不是为了现在，这一切只是源于passion。


在大海吐出的每个泡沫中
在上班路上吸入的每一粒尘埃中
在过去岁月的每一次阵痛中
在一次一次睡去和醒来中
在天气预报和新闻联播中
在七月流火和九月授衣中
在七月长生殿七日中
在矢车菊和芙蓉中
在长绳纪日中
在天长地久中
在你身边
在我心里
无须寻求意义

第八章 csh, pipes和find
强有力的工具给强有力的傻瓜


“有些操作系统从没有被好好计划，以至于只好用反刍的噪音来命名它的命令（awk,
grep, fsck, norff），我想到这个就反胃。”
—— 无名氏

UNIX所谓的“强大工具”是个骗局。 这不过是UNIX为了那些东拼西凑的命令和工具所打
的幌子。真正的强大工具不需要用户付出太多努力就能提供强大的功能。任何会使改锥
和钻头的人都会用电动改锥和电钻。他们不需要搞懂电学、电机、转矩、电磁学、散热
或维护。他们只需要把它通上电，带上安全眼镜，然后打开开关。许多人连安全眼镜也
不省了。你在五金商店里找不到有致命缺陷的工具：它们不是根本没能投放市场，就是
被诉讼搞得焦头烂额。

UNIX设计者的最初目标是提供简单的工具，然而现在的工具则充满了过分的设计和臃肿
的功能。比如ls这个列文件的命令竟然有18个选项，提供从排序到指定显示列数的种种
功能，而这些功能如果用其他程序实现会更好些（以前正是这样的）。Find命令除了查
找文件以外还输出cpio格式的文件（而这个功能其实用UNIX名声狼藉的管道很好地实现
）。今天，和UNIX类似的电钻将有20个旋钮，连着不标准的电源线，不匹配3/8英寸和7/
8英寸的钻头（而这一点会在手册的BUG一章中说明）。

和五金店里的工具不同，许多UNIX强大工具是有缺陷的（有时对文件是致命的）：比如t
ar的不接受超过100个字符的文件名；又比如UNIX调试器总是垮掉，这还不够，它的core
文件将覆盖你自己的core，让你下次可以用调试器去调试调试器在调试调试器中生成的c
ore。


Shell游戏

UNIX的发明人有个伟大的想法: 把命令解析器作为一个用户程序实现。如果用户不喜欢
缺省的命令解析器，他可以自己写一个。更重要的是，shell能够进化，这样shell将不
断进步，变得越来越强大，灵活和易用，至少理论上是这样。

这真是个伟大的想法，不过弄巧成拙了。功能的逐渐增加带来的是一团糟。因为这些功
能没有经过设计，只是在不断演化。和所有编程语言所遭到过的诅咒一样，那些利用这
些功能的既存shell脚本成为了shell的最大敌人。只要有新的功能加入shell，就会有人
在自己的脚本中使用它，这样这个功能就从此长生不老了。坏主意和臭功能往往怎么也
死不掉。

于是，你得到了一个不完整、不兼容的shell的大杂烩 （以下每个shell的描述都来自于
他们各自的man pages）：

sh 是个命令编程语言，用于执行来自终端或文件的命令。

Jsh 和sh一样，但具有csh风味的工作控制 (job control)

Csh C类型语法的shell

Tcsh emacs编辑口味的csh

Ksh KornShell，你的另一个命令和编程语言

Zsh Z Shell

Bash GUN Bourne-Again Shell (GNU Bourne复出Shell)


五金商店里的螺丝刀和锯子，尽管可能来自3、4个不同的厂商，但操作方法都差不多。
典型的UNIX在/bin或/usr/bin下存了成百个程序，它们来自众多自以为是的程序员，有
着自己的语法、操作范例、使用规则（这一个可以当成管道，而那一个则操作临时文件
），不同的命令行参数习惯，以及不同的限制。拿grep和它的变种fgrep, egrep来说，
哪一个是最快的？为什么它们接受的参数都不一样，甚至对正则表达式的理解也不尽相
同？为什么不能有一个程序提供所有功能？负责的家伙在哪儿啊？

当把命令之间的种种不同都深深烙在脑海中后，你还不能避免被惊着。

Shell Crash

下面这条消息来自哥伦比亚大学编译原理课程的BBS。

Subject: Relevant UNIX bug
October 11, 1991

W4115x课程的同学们：
我们刚学习了活动记录(activation record)，参数传递(argument passing)和函数调用
规则(calling conventions)，你们是否知道下面的输入将让任何一个cshell立刻崩溃？
：

!xxx%s%s%s%s%s%s%s%s

你们知道为什么么？

以下的问题供你们思考：

Shell遇到 “!xxx”会做什么？
Shell遇到 “!xxx%s%s%s%s%s%s%s%s”会做什么？
为什么cshell会崩溃?
你将如何修改有关代码来解决这个问题？


最重要的一点：

当你(是的，就是你)将这个前途远大的操作系统用21个字符治服的时候，你觉得天理能
容么？


你可以自己试一试。根据UNIX的设计，如果shell垮掉了，你的所有进程将被杀死，你也
会被踢出系统。其他操作系统在遇到非法内存访问错误时会弹出调试器，但不是UNIX。


可能这就是为什么UNIX shells不让你在shell的地址空间里动态加载自己的模块，或者
直接调用其他程序中的函数。如果这样就太危险了。一步走错，唉哟，你已经被踢出门
外了。愚蠢的用户是应该被惩罚的，程序员的错误更是不可容忍。


下回书里我们将进入色彩斑斓的UNIX语法世界。
---
说了世上一无牵挂为何有悲喜
说了朋友相交如水为何重别离
说了少年笑看将来为何常回忆
说了青春一去无悔为何还哭泣
warning3 发表于：2003-01-09 13:01

发帖： 359
注册： 1999-08-27
http://research.microsoft.com/~daniel/unix-haters.html

Table of Contents

Foreword, by Donald Norman
Preface
Anti-Foreword, by Dennis Ritchie
Part 1: User Friendly?
1 Unix. The World's First Computer Virus
2 Welcome, New User! Like Russian Roulette with Six Bullets Loaded
3 Documentation? What Documentation?
4 Mail. Don't Talk to Me, I'm Not a Typewriter
5 Snoozenet. I Post, Therefore I Am
6 Terminal Insanity. Curses! Foiled Again!
7 The X-Windows Disaster. How to Make a 50-MIPS Workstation Run Like a 4.77MHz IBM PC
Part 2: Programmer's System?
8 csh, pipes, and find. Power Tools for Power Fools
9 Programming. Hold Still, This Won't Hurt a Bit
10 C++. The COBOL of the 90s
Part 3: Sysadmin's Nightmare
11 System Administration. Unix's Hidden Cost
12 Security. Oh, I'm Sorry, Sir, Go Ahead, I didn't Realize You Were Root
13 The File System. Sure It Corrupts Your Files, But Look How Fast It Is!
14 NFS. Nightmare File System
Part 4: Et Cetera
A Epilogue. Enlightenment Through Unix
B Creators Admit C, Unix Were Hoax
C The Rise of Worse is Better, by Richard P. Gabriel
D Bibliography

(Editors note: this page is a verbatim reproduction of the preface in the published version of "The UNIX-HATERS Handbook." Here is the link back to "The UNIX-HATERS Handbook" home page.)


Preface


Things Are Going to Get a Lot Worse
Before Things Get Worse

"I liken starting one's computing career with Unix, say as an undergraduate, to being born in East Africa. It is intolerably hot, your body is covered with lice and flies, you are malnourished and you suffer from numerous curable diseases. But, as far as young East Africans can tell, this is simply the natural condition and they live within it. By the time they find out differently, it is too late. They already think that the writing of shell scripts is a natural act."

Ken Pier, Xerox PARC

Modern Unix is a catastrophe. It's the "Un-Operating System": unreliable, unintuitive, unforgiving, unhelpful, and underpowered. Little is more frustrating than trying to force Unix to do something useful and nontrivial. Modern Unix impedes progress in computer science, wastes billions of dollars, and destroys the common sense of many who seriously use it. An exaggeration? You won't think so after reading this book.

Deficient by Design

The original Unix solved a problem and solved it well, as did the Roman numeral system, the mercury treatment for syphilis, and carbon paper. And like those technologies, Unix, too, rightfully belongs to history. It was developed for a machine with little memory, tiny disks, no graphics, no networking, and no power. In those days it was mandatory to adopt an attitude that said: "Being small and simple is more important than being complete and correct." "You only have to solve 90% of the problem." "Everything is a stream of bytes."

These attitudes are no longer appropriate for an operating system that hosts complex and important applications. They can even be deadly when Unix is used by untrained operators for safety-critical tasks.


Ironically, the very attributes and design goals that made Unix a success when computers were much smaller, and were expected to do far less, now impede its utility and usability. Each graft of a new subsystem onto the underlying core has resulted in either rejection or graft vs. host disease with its concomitant proliferation of incapacitating scar tissue. The Unix networking model is a cacophonous Babel of Unreliability that quadrupled the size of Unix's famed compact kernel. Its window system inherited the cryptic unfriendliness of its character-based interface, while at the same time realized new ways to bring fast computers to a crawl. Its new system administration tools take more time to use than they save. Its mailer makes the U.S. Postal Service look positively stellar.


The passing years only magnify the flaws. Using Unix remains an unpleasant experience for beginners and experts alike. Despite a plethora of fine books on the subject, Unix security remains an elusive goal at best. Despite increasingly fast, intelligent peripherals, high-performance asynchronous I/O is a pipe dream. Even though manufacturers spend millions developing "easy-to-use" graphical user interfaces, few versions of Unix allow you to do anything but trivial system administration without having to resort to the 1970s-style teletype interface. Indeed, as Unix is pushed to be more and more, it instead becomes less and less. Unix cannot be fixed from the inside. It must be discarded.

Who We Are

We are academics, hackers, and professionals. None of us were born in the computing analog of Ken Pier's East Africa. We have all experienced much more advanced, usable, and elegant systems than Unix ever was, or ever can be. Some of these systems have increasingly forgotten names, such as TOPS-20, ITS (the Incompatible Timesharing System), Multics, Apollo Domain, the Lisp Machine, Cedar/Mesa, and the Dorado. Some of us even use Macs and Windows boxes. Many of us are highly proficient programmers who have served our time trying to practice our craft upon Unix systems. It's tempting to write us off as envious malcontents, romantic keepers of memories of systems put to pasture by the commercial success of Unix, but it would be an error to do so: our judgments are keen, our sense of the possible pure, and our outrage authentic. We seek progress, not the reestablishment of ancient relics.

Our story started when the economics of computing began marching us, one by one, into the Unix Gulag. We started passing notes to each other. At first, they spoke of cultural isolation, of primitive rites and rituals that we thought belonged only to myth and fantasy, of depravation and humiliations. As time passed, the notes served as morale boosters, frequently using black humor based upon our observations. Finally, just as prisoners who plot their escape must understand the structure of the prison better than their captors do, we poked and prodded into every crevice. To our horror, we discovered that our prison had no coherent design. Because it had no strong points, no rational basis, it was invulnerable to planned attack. Our rationality could not upset its chaos, and our messages became defeatist, documenting the chaos and lossage.


This book is about people who are in abusive relationships with Unix, woven around the threads in the UNIX-HATERS mailing list. These notes are not always pretty to read. Some are inspired, some are vulgar, some depressing. Few are hopeful. If you want the other side of the story, go read a Unix how-to book or some sales brochures.


This book won't improve your Unix skills. If you are lucky, maybe you will just stop using Unix entirely.

The UNIX-HATERS History

The year was 1987, and Michael Travers, a graduate student at the MIT Media Laboratory, was taking his first steps into the future. For years Travers had written large and beautiful programs at the console of his Symbolics Lisp Machine (affectionately known as a LispM), one of two state-of-the-art AI workstations at the Lab. But it was all coming to an end. In the interest of cost and efficiency, the Media Lab had decided to purge its LispMs. If Travers wanted to continue doing research at MIT, he discovered, he would have to use the Lab's VAX mainframe.

The VAX ran Unix.


MIT has a long tradition of mailing lists devoted to particular operating systems. These are lists for systems hackers, such as ITS-LOVERS, which was organized for programmers and users of the MIT Artificial Intelligence Laboratory's Incompatible Timesharing System. These lists are for experts, for people who can-and have-written their own operating systems. Michael Travers decided to create a new list. He called it UNIX-HATERS:


Date: Thu, 1 Oct 87 13:13:41 EDT
From: Michael Travers
To: UNIX-HATERS
Subject: Welcome to UNIX-HATERS
In the tradition of TWENEX-HATERS, a mailing list for surly folk who have difficulty accepting the latest in operating system technology.

If you are not in fact a Unix hater, let me know and I'll remove you. Please add other people you think need emotional outlets for their frustration.


The first letter that Michael sent to UNIX-HATERS included a well-reasoned rant about Suns written by another new member of the Unix Gulag: John Rose, a programmer at a well-known Massachusetts computer manufacturer (whose lawyers have promised not to sue us if we don't print the company's name). Like Michael, John had recently been forced to give up a Lisp Machine for a computer running Unix. Frustrated after a week of lost work, he sent this message to his company's internal support mailing list:

Date: Fri, 27 Feb 87 21:39:24 EST
From: John Rose
To: sun-users, systems

Pros and Cons of Suns


Well, I've got a spare minute here, because my Sun's editor window evaporated in front of my eyes, taking with it a day's worth of Emacs state.


So, the question naturally arises, what's good and bad about Suns?


This is the fifth day I've used a Sun. Coincidentally, it's also the fifth time my Emacs has given up the ghost. So I think I'm getting a feel for what's good about Suns.


One neat thing about Suns is that they really boot fast. You ought to see one boot, if you haven't already. It's inspiring to those of us whose LispMs take all morning to boot.


Another nice thing about Suns is their simplicity. You know how a LispM is always jumping into that awful, hairy debugger with the confusing backtrace display, and expecting you to tell it how to proceed? Well, Suns ALWAYS know how to proceed. They dump a core file and kill the offending process. What could be easier? If there's a window involved, it closes right up. (Did I feel a draft?) This simplicity greatly decreases debugging time because you immediately give up all hope of finding the problem, and just restart from the beginning whatever complex task you were up to. In fact, at this point, you can just boot. Go ahead, it's fast!


One reason Suns boot fast is that they boot less. When a LispM loads code into its memory, it loads a lot of debugging information too. For example, each function records the names of its arguments and local variables, the names of all macros expanded to produce its code, documentation strings, and sometimes an interpreted definition, just for good measure.


Oh, each function also remembers which file it was defined in. You have no idea how useful this is: there's an editor command called "meta-point" that immediately transfers you to the source of any function, without breaking your stride. ANY function, not just one of a special predetermined set. Likewise, there's a key that causes the calling sequence of a function to be displayed instantly.


Logged into a Sun for the last few days, my Meta-Point reflex has continued unabated, but it is completely frustrated. The program that I am working on has about 80 files. If I want to edit the code of a function Foo, I have to switch to a shell window and grep for named Foo in various files. Then I have to type in the name of the appropriate file. Then I have to correct my spelling error. Finally I have to search inside the file. What used to take five seconds now takes a minute or two. (But what's an order of magnitude between friends?) By this time, I really want to see the Sun at its best, so I'm tempted to boot it a couple of times.


There's a wonderful Unix command called "strip," with which you force programs to remove all their debugging information. Unix programs (such as the Sun window system) are stripped as a matter of course, because all the debugging information takes up disk space and slows down the booting process. This means you can't use the debugger on them. But that's no loss; have you seen the Unix debugger? Really.


Did you know that all the standard Sun window applications ("tools") are really one massive 3/4 megabyte binary? This allows the tools to share code (there's a lot of code in there). Lisp Machines share code this way, too. Isn't it nice that our workstations protect our memory investments by sharing code.


None of the standard Sun window applications ("tools") support Emacs. Unix applications cannot be patched either; you must have the source so you can patch THAT, and then regenerate the application from the source.


But I sure wanted my Sun's mouse to talk to Emacs. So I got a couple hundred lines of code (from GNU source) to compile, and link with the very same code that is shared by all the standard Sun window applications ("tools"). Presto! Emacs gets mice! Just like the LispM; I remember similar hacks to the LispM terminal program to make it work with Emacs. It took about 20 lines of Lisp code. (It also took less work than those aforementioned couple hundred lines of code, but what's an order of magnitude between friends?)


Ok, so I run my Emacs-with-mice program, happily mousing away. Pretty soon Emacs starts to say things like "Memory exhausted" and "Segmentation violation, core dumped." The little Unix console is consoling itself with messages like "clntudp_create: out of memory." Eventually my Emacs window decides it's time to close up for the day.


What has happened? Two things, apparently. One is that when I created my custom patch to the window system, to send mouse clicks to Emacs, I created another massive 3/4 megabyte binary, which doesn't share space with the standard Sun window applications ("tools").


This means that instead of one huge mass of shared object code running the window system, and taking up space on my paging disk, I had two such huge masses, identical except for a few pages of code. So I paid a megabyte of swap space for the privilege of using a mouse with my editor. (Emacs itself is a third large mass.)


The Sun kernel was just plain running out of room. Every trivial hack you make to the window system replicates the entire window system. But that's not all: Apparently there are other behemoths of the swap volume. There are some network things with truly stupendous-sized data segments. Moreover, they grow over time, eventually taking over the entire swap volume, I suppose. So you can't leave a Sun up for very long. That's why I'm glad Suns are easy to boot!


But why should a network server grow over time? You've got to realize that the Sun software dynamically allocates very complex data structures. You are supposed to call "free" on every structure you have allocated, but it's understandable that a little garbage escapes now and then because of programmer oversight. Or programmer apathy. So eventually the swap volume fills up! This leads me to daydream about a workstation architecture optimized for the creation and manipulation of large, complex, interconnected data structures, and some magic means of freeing storage without programmer intervention. Such a workstation could stay up for days, reclaiming its own garbage, without need for costly booting operations.


But, of course, Suns are very good at booting! So good, they sometimes spontaneously boot, just to let you know they're in peak form!


Well, the console just complained about the lack of memory again. Gosh, there isn't time to talk about the other LispM features I've been free of for the last week. Such as incremental recompilation and loading. Or incremental testing of programs, from a Lisp Listener. Or a window system you can actually teach new things (I miss my mouse-sensitive Lisp forms). Or safe tagged architecture that rigidly distinguishes between pointers and integers. Or the Control-Meta-Suspend key. Or manuals.


Time to boot!


John Rose sent his email message to an internal company mailing list. Somehow it was forwarded to Michael Travers at the Media Lab. John didn't know that Michael was going to create a mailing list for himself and his fellow Unix-hating friends and e-mail it out. But Michael did and, seven years later, John is still on UNIX-HATERS, along with hundreds of other people.

At the end of flame, John Rose included this disclaimer:


[Seriously folks: I'm doing my best to get our money's worth out of this box, and there are solutions to some of the above problems. In particular, thanks to Bill for increasing my swap space. In terms of raw CPU power, a Sun can really get jobs done fast. But I needed to let off some steam, because this disappearing editor act is really getting my dander up.]

Some disclaimer. The company in question had bought its Unix workstations to save money. But what they saved in hardware costs they soon spent (and continue to spend) many times over in terms of higher costs for support and lost programmer productivity. Unfortunately, now that we know better, it is too late. Lisp Machines are a fading memory at the company: everybody uses Unix. Most think of Unix as a pretty good operating system. After all, it's better than DOS.

Or is it?

You are not alone

If you have ever used a Unix system, you have probably had the same nightmarish experiences that we have had and heard. You may have deleted important files and gone for help, only to be told that it was your own fault, or, worse, a "rite of passage." You may have spent hours writing a heart-wrenching letter to a friend, only to have it lost in a mailer burp, or, worse, have it sent to somebody else. We aim to show that you are not alone and that your problems with Unix are not your fault.

Our grievance is not just against Unix itself, but against the cult of Unix zealots who defend and nurture it. They take the heat, disease, and pestilence as givens, and, as ancient shamans did, display their wounds, some self-inflicted, as proof of their power and wizardry. We aim, through bluntness and humor, to show them that they pray to a tin god, and that science, not religion, is the path to useful and friendly technology.


Computer science would have progressed much further and faster if all of the time and effort that has been spent maintaining and nurturing Unix had been spent on a sounder operating system. We hope that one day Unix will be relinquished to the history books and museums of computer science as an interesting, albeit costly, footnote.

Contributors and Acknowledgments

To write this book, the editors culled through six years' archives of the UNIX-HATERS mailing list. These contributors are referenced in each included message and are indexed in the rear of the volume. Around these messages are chapters written by UNIX-HATERS experts who felt compelled to contribute to this expose.

We are:


Simson Garfinkel, a journalist and computer science researcher. Simson received three undergraduate degrees from the Massachusetts Institute of Technology and a Master's degree in journalism from Columbia University. He would be in graduate school working on his Ph.D. now, but this book came up and it seemed like more fun. Simson is also the co-author of Practical Unix Security (O'Reilly and Associates, 1991) and NeXTSTEP Programming (Springer-Verlag, 1993). In addition to his duties as editor, Simson wrote the chapters on Documentation, the Unix File System, Networking, and Security.


Daniel Weise, a researcher at Microsoft's research laboratory. Daniel received his Ph.D. and Master's degrees from the Massachusetts Institute of Technology's Artificial Intelligence Laboratory and was an assistant professor at Stanford University's Department of Electrical Engineering until deciding to enter the real world of DOS and Windows. While at his cushy academic job, Daniel had time to work on this project. Since leaving Stanford for the rainy shores of Lake Washington, a challenging new job and a bouncing, crawling, active baby boy have become his priorities. In addition to initial editing, Daniel wrote large portions of Welcome, New User; Mail; and Terminal Insanity.


Steven Strassmann, a senior scientist at Apple Computer. Steven received his Ph.D. from the Massachusetts Institute of Technology's Media Laboratory and is an expert on teaching good manners to computers. He instigated this book in 1992 with a call to arms on the UNIX-HATERS mailing list. He's currently working on Apple's Dylan development environment.


John Klossner, a Cambridge-based cartoonist whose work can be found littering the greater northeastern United States. In his spare time, John enjoys public transportation.


Donald Norman, an Apple Fellow at Apple Computer, Inc. and a Professor Emeritus at the University of California, San Diego. He is the author of more than 12 books including The Design of Everyday Things.


Dennis Ritchie, Head of the Computing Techniques Research Department at AT&T Bell Laboratories. He and Ken Thompson are considered by many to be the fathers of Unix. In the interest of fairness, we asked Dennis to write our Anti-Foreword.


Scott Burson, the author of Zeta C, the first C compiler for the Lisp Machine. These days he makes his living hacking C++ as a consultant in Silicon Valley. Scott wrote most of the chapter on C++.


Don Hopkins, a seasoned user interface designer and graphics programmer. Don received a BSCS degree from the University of Maryland while working as a researcher at the Human Computer Interaction Lab. Don has worked at UniPress Software, Sun Microsystems, the Turing Institute, and Carnegie Mellon University. He ported SimCity to NeWS and X11 for DUX Software. He now works for Kaleida. Don wrote the chapter on the X-Windows Disaster. (To annoy X fanatics, Don specifically asked that we include the hyphen after the letter "X," as well as the plural on the word "Windows," in his chapter title.)


Mark Lottor, who has actively hated Unix since his first Usenix conference in 1984. Mark was a systems programmer on TOPS-20 systems for eight years, then spent a few years of doing Unix system administration. Frustrated by Unix, he now programs microcontrollers in assembler, where he doesn't have to worry about operating systems, shells, compilers, or window systems getting in the way of things. Mark wrote the chapter on System Administration.


Christopher Maeda, a specialist on operating systems who hopes to have his Ph.D. from Carnegie Mellon University by the time this book is published. Christopher wrote most of the chapter on Programming.


Rich Salz is a Principal Software Engineer at the Open Software Foundation, where he works on the Distributed Computing Environment. Rich has been active on the Usenet for many years; during his multiyear tenure as moderator of comp.sources.unix he set the defacto standards for Usenet source distribution still in use. He also bears responsibility for InterNetNews, one of the most virulent NNTP implementations of Usenet. More importantly, he was twice elected editor-in-chief of his college newspaper, The Tech, but both times left school rather than serve out his term. Rich wrote the Snoozenet chapter.


In producing this book, we have used and frequently incorporated messages from Phil Agre, Greg Anderson, Judy Anderson, Rob Austein, Alan Bawden, Alan Borning, Phil Budne, David Chapman, Pavel Curtis, Mark Friedman, Jim Davis, John R. Dunning, Leonard N. Foner, Simson Garfinkel, Chris Garrigues, Ken Harrenstien, Ian D. Horswill, Bruce Howard, David H. Kaufman, Tom Knight, Robert Krajewski, James Lee Johnson, Jerry Leichter, Jim McDonald, Dave Mankins, Richard Mlynarik, Nick Papadakis, Michael A. Patton, Kent M. Pitman, Jonathan Rees, Stephen E. Robbins, M. Strata Rose, Robert E. Seastrom, Olin Shivers, Patrick Sobalvarro, Christopher Stacy, Stanley's Tool Works, Steve Strassmann, Michael Tiemann, Michael Travers, David Vinayak Wallace, David Waitzman, Dan Weinreb, Daniel Weise, John Wroclawski, Gail Zacharias, and Jamie Zawinski.


The Unix Barf Bag was inspired by Kurt Schmucker, a world-class C++ hater and designer of the infamous C++ barf bag. Thanks, Kurt.


We received advice and support from many people whose words do not appear here, including Beth Rosenberg, Dan Ruby, Alexander Shulgin, Miriam Tucker, David Weise, and Laura Yedwab.


Many people read and commented on various drafts of this manuscript. We would especially like to thank Judy Anderson, Phil Agre, Regina C. Brown, Michael Cohen, Michael Ernst, Dave Hitz, Don Hopkins, Reuven Lerner, Dave Mankins, Eric Raymond, Paul Rubin, M. Strata Rose, Cliff Stoll, Len Tower Jr., Michael Travers David Waitzman, and Andy Watson. A special thanks to all of you for making many corrections and suggestions, and finding our typos. We would especially like to thank Matthew Wagner at Waterside Productions. Matt immediately gravitated to this book in May 1992. He was still interested more than a year later when Simson took over the project from Daniel. Matt paired us up with Christopher Williams at IDG Programmers Press. Chris signed us up without hesitation, then passed us on to Trudy Neuhaus, who saw the project through to its completion. Amy Pedersen was our Imprint Manager. The UNIX-HATERS cover was illustrated by Ken Copfelt of The Stock Illustration Source.

Typographical Conventions

In this book, we use this roman font for most of the text and a different sans serif font for the horror stories from the UNIX-HATERS mailing list. We've tried to put command names, where they appear, in bold, and the names of Unix system functions in italics. There's also a courier font used for computer output, and we make it bold for information typed by the user. That's it. This isn't an unreadable and obscure computer manual with ten different fonts in five different styles. We hate computer manuals that look like they were unearthed with the rest of King Tut's sacred artifacts.

This book was typeset without the aid of troff, eqn, pic, tbl, yuc, ick, or any other idiotic Unix acronym. In fact, it was typeset using FrameMaker on a Macintosh, a Windows box, and a NeXTstation.

The UNIX-HATERS Disclaimer

In these days of large immoral corporations that compete on the basis of superior software patents rather than superior software, and that have no compunctions against suing innocent universities, we had better set a few things straight, lest they sic an idle lawyer on us:

It might be the case that every once in a while these companies allow a programmer to fix a bug rather than apply for a patent, so some of the more superficial problems we document in this book might not appear in a particular version of Unix from a particular supplier. That doesn't really matter, since that same supplier probably introduced a dozen other bugs making the fix. If you can prove that no version of Unix currently in use by some innocent victim isn't riddled with any of the problems that we mention in this volume, we'll issue a prompt apology.


Inaccuracies may have crept into our narrative, despite our best intentions to keep them out. Don't take our word for gospel for a particular flaw without checking your local Unix implementation.


Unix haters are everywhere. We are in the universities and the corporations. Our spies have been at work collecting embarrassing electronic memoranda. We don't need the discovery phase of litigation to find the memo calculating that keeping the gas tank where it is will save $35 million annually at the cost of just eight lives. We've already got that memo. And others.

Editors of "The Unix-Haters handbook", [email protected]
---
*** Do you segfault today?! ***
scz 发表于：2003-01-14 10:53
第八章 csh, pipes和find (part 2)

张贴者： pengchengzou (veteran)
张贴日期 01/13/03 11:24

半年前的上回书说到你如何去玩shell游戏，估计现在你已经玩腻了，不过不要
着急，下面，该轮到shell玩你了。


欢迎来到元语法(metasyntacitic)动物园

C Shell的元语法操作符带来了大量和引用有关的问题和混乱。元操作符在一个
命令被执行前对其进行转换。我们把这些操作符叫做元操作符是因为它们不属于
命令的语法成分，它们作用于命令本身。大多数程序员对元操作符(有时也叫做
escape operators)并不陌生。比如，C字符串中的反斜杠(\)就是一个元语法操
作符；它不代表自己，而是对其后的字符的说明。如果你不希望如此，你必须使
用引用机制来告诉系统把元操作符当做一般字符来处理。回到刚才C字符串的例
子，如果想得到反斜杠字符，你必须写成\\。

简单的引用机制在C Shell中很难工作，这是因为Shell和它执行的程序之间各执
一词，无法统一。例如，下面是个简单的命令：


grep string filename;

参数string包含了grep定义的字符，比如?, [, 和]等等，
但这些字符是shell的元操作符。这意味着必须对它们进行引用。然而，有些时
候可能不需要如此，这和你使用什么样的shell以及环境变量有关。

如果想在字符串中寻找包含点(.)或其他以横杠(-)开头的模式，这就更为复杂了。

一定要记住对元字符进行正确引用。不幸的是，和模式识别一样，操作系统的各
个部分都充斥着互不兼容的引用标准。

C Shell的元语法动物园里饲养着七种不同的元操作符家族。斗转星移，
转眼间动物园里已经人满为患了，笼子使用的不再是钢铁，而是用锡了。动物间
的小磨擦不断。这七种针对shell命令行的转换方式是：

别名 alias, unalias

命令输出替代 `

文件名替代 *, ?, []

历史替代 !, ^

变量替代 $, set, unset

进程替代 %

引用 ',"


这一“设计”的结果是，问号(?)永远被shell当成单字符匹配符，它永远无法被
作为命令行参数传给用户程序，所以别想使用问号来作为帮助选项。

如果这七种元字符有着清晰的逻辑顺序和定义，那么情况也不会太糟糕。可事实
并非如此：


日期: Mon, 7 May 90 18:00:27 - 0700
发信人: Andy Beals <[email protected]>
主题: Re: today's gripe: fg %3 (今天之不爽事：fg %3)
收信人: UNIX-HATERS

你可以使用%emacs或者%e来恢复一个任务（如果唯一的话），也可以使
用%?foo，如果"foo"出现在命令行中。

当然，!ema和!?foo也可以用于历史命令替换上。

但是，UCB的猪头(pinheads)们没有想到!?foo后面可能伴随的编辑命令：

!?foo:s/foo/bar&/:p

多向前扫描一个编辑字符真的这么困难么？


哪怕是Unix“专家”，也要晕菜了。下面再来看看Milt Epstein的这个例子，他
想写个shell脚本获得实际被敲入的命令行，而不是那个经shell处理后的
结果。他最后发现这并不容易，因为shell为命令做了太多的“好事”。要做到
这一点，需要各种稀奇古怪的变形技术，连Unix专家也会望而却步。这就是Unix
的典型做法：把简单的东西搞得异常复杂，这只是因为这些东西在Unix诞生之时
从没被仔细考虑过：


日期: 19 Aug 91 15:26:00 GMT
发信人: [email protected]
主题: ${1+"$@"} in /bin/sh family of shells shell scripts
收信人: comp.emacs.gnu.emacs.help, comp.unix.shell

>>>>> On Sun, 19 Arg 91 18:21:58 - 0500
>>>>> Milt Epstein <[email protected]>
写到：

Milt> "${1+"$@"}"究竟是什么意思？我估计这是用来
Milt> 读取其余的命令行参数，但我不敢肯定。

这是/bin/sh里用来完整复制命令行参数的一种方法。

它的意思是：如果有至少一个参数(${1+)，那么用所有参数("$@")来替
代以保留所有的空白字符。

如果我们只使用"$@"，那么在没有参数的情形下会得到""而不是我们想
要的空参数。

那么，为什么不使用"$*"呢？sh(1)的man手册是这样说的：

双引号之间的参数和命令会被替换，shell会对结果加上引用，
以避免解析空格或生成文件名。如果$*出现在双引号之中，各
个参数之间的空格会被加上引用("$1 $2 ...")，而如果$@出
现在双引号之中，各个参数之间的空格不会被加上引用("$1"
"$2" ...)。

我认为${1+"$@"}一直可以兼容到“版本7”的shell。


老天！一直兼容到“版本7”。


听"chdir"的还是听"cd"的？

Unix在漫长的演化过程中几经易手，这些Unix系统开发者把Unix引向了不同方向，

他们之中没有一个人停下来考虑一下自己的做法会不会对和其他人发生冲突。


日期: Mon, 7 May 90 22:58:58 EDT
发信人: Alan Bawden <[email protected]>
主题: cd ..: I am not making this up (cd ..: 这不是我编造出来的)
收信人: UNIX-HATERS

有什么命令能比"cd"更直接了当的呢？让我们看这个简单的例子："cd
ftp"。如果我的当前目录/home/ar/alan中有个子目录叫做"ftp"，那么
它就变成了我新的当前目录，现在我在/home/ar/alan/ftp下了。简单
吧？

现在，你们知不知道"."和".."？每个目录都会有两个记录："."是指该
目录自己，".."是指父目录。在上面的例子中，如果我想回到
/home/ar/alan，只要敲"cd .."就可以了。

现在假设"ftp"是一个符号链接。假设它指向的是目录
/com/ftp/pub/alan。如果执行"cd ftp"，我的当前目录将是
/com/ftp/pub/alan。

和其他所有目录一样，/com/ftp/pub/alan也有一个叫".."的记录，它
指的是父目录：/com/ftp/pub。如果我想进入那个目录，我敲入命令：

% cd ..

猜一下我现在在哪儿呢？我又回到了/home/ar/alan！shell(准确的说
是人工智能实验室里用的tcsh)认为我其实是想回到那个装有符号链接
的目录。现在我必须使用"cd ./.."才能进入/com/ftp/pub。



Shell编程

Shell程序员和《侏罗纪公园》里的恐龙制造者