Chinaunix首页 | 论坛 | 博客
  • 博客访问: 1694010
  • 博文数量: 177
  • 博客积分: 9416
  • 博客等级: 中将
  • 技术积分: 2513
  • 用 户 组: 普通用户
  • 注册时间: 2006-01-06 16:08
文章分类

全部博文(177)

文章存档

2013年(4)

2012年(13)

2011年(9)

2010年(71)

2009年(12)

2008年(11)

2007年(32)

2006年(25)

分类: BSD

2007-09-04 13:19:23

第三章 文档

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
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
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
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: cj@eno.corp.sgi.com (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。


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




阅读(1556) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~