Unix 的管道实在是一个好用的东西，利用管道可以很方便的把一些简单的工具结合起来完成一些复杂的任务。这里不想解释什么是 Unix 的管道，也不举具体的例子来展示管道的方便之处，只是想通过一个现实中管道的例子来说明为什么管道是好东西，为下一篇文章写管道的思想在写程序时的应用做准备。

正如其名字暗示的，Unix 的管道其实跟现实生活中的管道非常类似。要注意的是这里讨论的管道不只是为了传送液体（或者气体），还可能对液体进行一些处理。构成管道最主要的东西其实就是一节一节管子/过滤器。液体从管道的一端流入，经过各个过滤器的处理，从另一端流出时可能已经是另外的液体了。流出什么样的液体取决于流入的液体和组成管道的过滤器，很显然决定管道功能的是构成管道的每一个过滤器。现在假设我要进行污水处理，污水里有沙子，还有各种溶解在其中的物质。我可以做一个只含一个过滤器的管道，这个过滤器可以把沙子和溶解物一次性全部过滤掉。

但如果再来一批污水，只含有沙子，那用之前的这个过滤器显然太浪费了；或者，新的污水含有原先污水中没有的溶解物，那只用原先的过滤器是不够的。比较好的做法是用一个过滤器过滤沙子，每种溶解物用一个过滤器（现实中的污水处理当然不可能这么简单，这里只是以此为例子），污水里需要过滤什么就在管道上加上什么过滤器。

这样做的好处有几个：

1. 每个过滤器做起来都比较简单，因此每个过滤器的制造成本降低了
2. 过滤器更可能被重复使用
3. 易于处理各种不同的污水，只需要重新组合下过滤器就可以了，而不需要为每种污水设计一个过滤器

Unix 的管道其实就是模仿了现实生活中的管道，只不过流经管道的是数据（多数时候是文本），构成过滤器的是 Unix 下的那些小工具。Unix 中使用管道的好处与污水处理的例子里是类似的

1. 每一个工具只完成一个很简单的任务，因此每个工具都很容易实现
2. 每个工具更有可能被用到，而工具重用的成本几乎为 0
3. 更加灵活（见下面的例子）

有些管道的用法真是让人感叹，比如现在的 Linux 版 QQ 收到消息是没有声音的，有人用 tcpdump, sed, aplay 组合自己山寨了这个功能出来。还有听小百合的 lv 说他用 mplayer,gzip, netcat 等工具做了一个视频监控系统出来。QQ 的那个例子做法如下：

sudo tcpdump -i ppp0 -l udp src port 8000 and ip[0x20]=0x17 | \
    sed -u '/.*$/s//aplay msg.wav/' | sh

前面说过，管道的功能是由过滤器决定的。光由操作系统提供一个构建管道的机制是没有什么大用处的。Unix 管道的强大关键还在于那些小工具的设计。

从一开始，那些小工具的设计就考虑到了通过管道来配合使用（我觉得应该是管道的存在影响了这些工具的设计，而不是反过来，不知道 Unix 的历史是否的确如此），因此这些工具有几个显著的特点

1. 功能简单，有的工具简单到单独看觉得根本就没什么用
2. 以文本作为交互的数据，人能读，程序也能读
3. 功能上尽可能正交，每个工具完成自己的任务，不跟其他工具的功能重复（awk,sed 这样的程序功能上还是有些重复的，当然有时候一件事情能用多种方式完成也是好事。）

软件开发的成本与其复杂度不是线性关系，再加上每个工具都得到了更多的重用，组合起来还可以实现新的功能，考虑到这几点，使用管道可以节省的系统工具开发成本就不是一点点了。当然，光节省成本而不好用那也没意义，但事实是管道很有用。

每个工具都只执行简单的任务也有一点麻烦，一些相对简单的任务也可能需要调用好几个工具，此时可以把常用的命令组合可以存到脚本里。这就相当于把管道存起来，以后直接用这个管道而不用再重新把过滤器搭起来了。另一个方面是用户需要花相对来说比较多的时间来学习这些工具，对于经常要使用电脑的人来说，考虑下学习这些工具以后能得到的收益，花些时间是完全值得的。（对那些偶尔使用的人来说可能就不划算了。）

关于管道和 Unix 的设计哲学，在 Eric S. Raymond 的 “The Art of UNIX Programming” 中有着更多的介绍。（该死的 GFW 把 Raymond 的主页都墙了。）

Unix 管道的好处我们已经看到了，那可不可以在写程序时也使用这样的思想呢？当然可以！下一篇文章我就要谈在程序中如何使用管道的思想。以 Python 为例，介绍 generator，还有为什么 lazy evaluation 也是好东西 :)