保持我们最初的理想，当面对无数歧路

保持我们最初的理想，当面对无数歧路

本文以实例非常粗浅地介绍Linux下的工具 find, grep, tar
的使用，还有正则表达式。侯捷先生用这些工具帮助写了<STL源码剖析>和<深入浅出MFC>，我们将用这些工具帮助编译一个叫做calltree的小工具。

本文还讨论了如何保持最初的理想。

0. calltee

calltree是个静态分析C代码中的函数调用关系的工具，用来画 call
graph。为了找个工具帮助画几个模块间的依赖关系，找到了它。刚刚这句你看不懂也没关系，你知道calltree是个程序就行了。事实上，大部分文章中的大部分话你看不懂，都没关系。直到因为你不知道这段话所提供的事实影响了你的阅读，那才有关系了。

1. 多歧路

在你读某段话时，如果没有完全读懂，那么宇宙会因此而分裂成为无数条分支，每条分支对应这段话的一种含义的可能。但是，这没有什么影响，你大可以把这些分支都忘了。不过，当你继续读，后面某一段可能会用到刚刚那句话提供的信息了，此时，因为你的注视，所有那些分支宇宙就坍缩为唯一的一个。如果你不知道那句话的确切含义，随着一步步深入，分支就会呈爆炸状迅速增长。

初学者在涉足某个领域的时候，所面临的正是这个问题--在每一步中，可能性都太多了，稍有不慎就拐进了一个死胡同。而且越走越远，接下来全是无用功。正是因为这个，我们要在每一步中检查自己当前的状态，而不能等到最后。

经常有同学问到，为什么我这段程序编译通不过呢？你要来他的程序一看，好几百行，编译一下，错误在第十几行。如果前面的你都没有通过，为什么要继续向下走呢，后面那好几百行都是怎么写出来的啊。

这是理工类的一个重要特点，如果当前的一步没有处理好，未来很难弥补。事实上，能在未来弥补现在的错误，是个巨牛的活儿。一般地，如果你幼稚到现在会犯这样的错误，基本可以断定，你不具备在未来弥补的能力。

所以写代码的时候，如果你承认自己不够牛
(通常如此)，那么你应该写一会代码就编译一下，让编译器帮助检查错误。有同学说，我还得一阵才能写到下一个"括回}"呢。你应该在写"{"的下一个字符就写"}"，然后再写中间的部分。步子要保证足够小，能在足够短的时间内编译，从而得到检验。如果航海技术不够发达，就应该珍惜生命，不远离陆地，在能看到海岸的地方航行。铁子同学，你是不是想起了《文明II》？

为了回避失败感，初学者们经常想要计划得非常周全，按他们的话说，"我想等想好了的再动手"。他们太骄傲了，计划，这是世界上最难的事实，远远比动手再失败要难很多个数量级。尤其是，你计划这件事情的时候，你尚不知道未来会遇到哪些问题--如果你知道，那么你就是这个并非陌生的领域的专家了。所谓初学者，就是两眼一抹黑地往前走的人。你不走，就永远也不会熟悉这个领域。

2. 解压

你说什么，等专家引领？专家哪有那个功夫。

比如安装calltree。你随便搜索一下，就有人告诉你从哪个网址下载。你下载完了，文件名是 "calltree-2.3.tar.bz2"。

你可能认识不少扩展名，认识 tar.gz，认识 zip，认识 rar，甚至还认识7z。可是bz2是什么？

大家一般的选择：1.找个支持bz2解压的工具，2.搜索一下，3.QQ上找个好友，"bz2怎么解压？"
最后这种人后来就被QQ好友拉黑了。有位大侠在网上提到： tar jxvf
calltree-2.3.tar.bz2。这也可能是你的QQ好友告诉你的。在命令行下跑一遍，你得到了 calltree-2.3 目录。

看起来解压完成了，很多人以为这一节就结束了。不过，在这个时刻，你可能没有注意到，宇宙分裂了。 tar jxvf
是什么意思，你没有注意，它存在各种可能，等到你再遇到需要它的时候，世界将坍缩为"你还是不会"。

这段话的意思，你当然可以搜索一下，或者QQ (你永远可以QQ别人，因此以后这条选择略掉)，不过Linux/Unix的习惯是手册里有主要的信息。

我们执行：
$ tar --help | grep \-j
-j, --bzip2 filter the archive through bzip2

然后我们就明白了，j的作用是"filter the archive through
bzip2"，原来是用bzip2解压缩的。我们的文档刚好是bz2扩展名，合理合理。

"tar --help"会输出tar的所有帮助。有不少人习惯于把 tar --help 全输出来，然后用眼睛找想要的信息。

如果你知道自己想要什么，那么可以直接告诉计算机，而不用自己再亲力亲为。对大量数据的重复工作，计算机比我们擅长，只要我们指令明确。grep就是干这个用的。grep是一个过滤器，它把符合条件的留下来。"-j"前面的那个"\"，是因为"-"是个特殊字符，它的后面是grep的参数，"\"的作用是避免grep把"-j"作为参数，而是作为过滤条件。

如果你不知道自己想要什么，就只能在歧路中摸索；如果你知道自己的目标，那么，就可以直接命中，无需犹豫。大毅同学问我，为什么要看康德呢。我说，因为我想要过毫不犹豫的生活。道理是一样的。

初学者和专家最大的区别在于，专家不必尝试，他知道应该如何做，知道这样做的结果如何，甚至还知道误差和出错的概率有多大，甚至还知道如果出错如何改善。这些"如何"的难度，从前向后，越来越大。

2. make失败

解压以后，按Linux下从源代码编译安装，惯例就是进目录，读INSTALL文件；或者不读，直接跑configure或者make。

我make，然后出了一大堆错误。有的同学可能就要一行行找错误了，用眼睛。这很难，因为make的输出信息长达511行。这个数据也不是我一行行查的，而是：

$ make | wc -l
511

你要到哪里找错误呢？先想想错误信息的特征是什么。没错，"error"。所以，我们再用 grep。

$ make | grep -i "error"
../include/schily.h:186: error: conflicting types for 'getline'
make[2]: *** [OBJ/i686-linux-cc/avoffset.o] Error 1
make[1]: *** [all] Error 2
../include/schily.h:110: error: conflicting types for 'fexecve'
../include/schily.h:186: error: conflicting types for 'getline'
make[2]: *** [OBJ/i686-linux-cc/cvmod.o] Error 1
make[1]: *** [all] Error 2
../include/schily.h:110: error: conflicting types for 'fexecve'
../include/schily.h:186: error: conflicting types for 'getline'
make[1]: *** [OBJ/i686-linux-cc/calltree.o] Error 1
~/Downloads/calltree-2.3 $

这错误有点让人感到莫名其妙，因为getline和fexecve是两个著名的函数，你甚至能man出来它们，是posix的一部分。又或者你根本不知道它们是什么也行，你就会觉得，"这源代码不是应该一编译就通过吗，搞什么..."

3. 修改源代码

搜索一下，我找到了EnuLL大侠的博客[http://www.3null.org/?p=439]，他说，"在比较新的内核（glibc库）上编译，会出现编译不过的问题。具体现象大概像下面这个样子..."
这个样子，就是你上面看到的样子。

然后EnuLL大侠说，"具体解决办法有两种，一种就是给glibc打patch，另一种就麻烦点，把冲突的命名手动都改了。"

关于解决方案，这句话到这里就完了，初学者就也完了。打patch，怎么打啊，手动改命名，怎么改啊。此处说来话长，我略过吧。总之，我们就知道，应该这样手动命名：把calltree源代码里所有声明、定义、调用这两个函数的地方，都把这两个函数改个名字。只要新的名字不再与posix的重名，那就没冲突了，编译就能通过了。

好了，目标明确了，你打算怎么动手？

有同学可能又想到了，一个个打开文件，然后有可能一行行看，用眼睛找到它们。或者，如果你有个够好的IDE，能全工程全文搜索--但是有时候你正用的项目恰恰不能在这个IDE上打开。再好的IDE和恒久远的钻石都是浮云，只有纯文本才是永恒的。

我们这样：

$ find . -name "*.[c|h]" -exec grep getline -nH {} \;
./include/schily.h:117:extern int fgetline __PR((FILE *, char *, int));
./include/schily.h:186:extern int getline __PR((char *, int));
./calltree/calltree.c:852: while (fgetline(fp, fname, sizeof(fname)) >= 0)
./libschily/stdio/fgetline.c:1:/* @(#)fgetline.c 1.6 03/06/15
Copyright 1986, 1996-2003 J. Schilling */
./libschily/stdio/fgetline.c:29:fgetline(f, buf, len)
./libschily/stdio/fgetline.c:67:getline(buf, len)
./libschily/stdio/fgetline.c:71: return (fgetline(stdin, buf, len));

从输出结果中能够看到：
(1) 在 include/schily.h的186行，是getline的声明；
(2) libschily/stdio/fgetline.c第67行，也提到了getline，查看代码以后发现，这是getline的定义；
(3) 奇怪，我没有找到调用getline的地方，不调用为什么要声明和定义。
(4) 那些fgetline是误伤的。

再来看产生这个结果的命令，"find . -name "*.[c|h]" -exec grep getline -nH {} \;"。有点乱，我们一段一段看。

find是个命令，找符合条件的文件。

(1) "find . -name"的意思是在当前目录"."下，找文件名符合条件的。

(2) "*.[c|h]"就是文件名要符合的条件。这是个正则表达式，意思是文件名任意("*")，扩展名(从"."开始)是"c"或者是"h"。我对正则表达式的运用还不是那么本能，所以实践操作中，没有先想到用正则表达式，而是先找了文件名为"*.c"的，然后找了文件名为"*.h"的。这也是典型的幼推的初学者的表现--不能一次性全部地了解自己的想法。

(3) "-exec ... {}... \;"。"-exec"的作用是，对find到的符合条件的文件，都施加一个动作 (命令)
，在本例中，这个动作就是grep。"{}"就代表找到的文件在这个命令中的位置。";"的作用是标识"-exec"的命令部分结束了，"\"是避免shell把";"当作find这个命令和下一个命令分隔符。wikipedia说得更明白一些，"The
semicolon (backslashed to avoid the shell interpreting it as a command
separator) indicates the end of the command."

如果找到的文件是 gold.c，那么"-exec"以后的部分相当于：grep getline -nH gold.c。注意，gold.c刚好取代了"{}"。

(4)"grep getline -nH {}"。grep是按正则表达式
(或退化为字符串)在文本中找到符合条件的行。"getline"是要匹配的正则表达式，在本例中，是我们要找到的那个函数。"{}"的意思上面说过了，代表find找到的文件，"-nH"的意思是打印出文件名和行号，你可以这样知道：

$ grep --help | grep \-H
-H, --with-filename print the filename for each match
$ grep --help | grep \-n,
-n, --line-number print line number with output lines

(5) 以上连起来，就是 "find . -name "*.[c|h]" -exec grep getline -nH {} \;"。

含义是：在当前目录下，找到所有的*.c和*.h；然后在这些文本文件的正文中，找到存在"getline"字样的地方。

然后呢？然后我们用文本编辑器打开那几个文件，找到对应的地方。我把getline都改为 getline_calltree。

然后呢？然后把 fexecve 也都改了，我改成 fexecve_calltree。

4. 可以更自动化

本例中，要改的地方不过五六处而已。如果要改的地方特别多呢？有个工具，叫做sed。

5. 再make

再make，通过了。为什么知道通过了呢？

我们执行
$ make | grep -i "error"

没有输出。没有消息就是好消息。

在".../OBJ/"下，我们得到了 calltree 文件，是可执行的。


6. 回顾歧路

每一个步骤，如果我们不选用自动化的 (批量的)
工具，我们都可能更倾向于陷入细节当中，迷失方向。尤其当我们是初学者的时候，我们尚不知道眼睛该往哪里看。这些细节具有多种可能性，很多步骤的多种可能性叠加起来，我们的面前摆着的就是一张非常复杂的网，每个节点都通向好几个地方。

我们总觉得眼前的就是最重要的，"活在当下"。就这样，我们被眼前的细节引导向完全不同的没有预期的方向；就这样，我们忘掉了最初的理想。

--------------------

博客会手工同步到以下地址：

[http://giftdotyoung.blogspot.com]

[http://blog.csdn.net/younggift]
。