进程间通信的技术细节繁杂，以Linux 系统为例，就有文件，管道，消息队列，信号量，RPC，UNIX Socket,　RPC　等等多种方式。Windows 系统还有邮件槽, COM 对象等等。Mac OS 则有 AppleEvent 等等。在这里我们介绍 Plan 9 系统中一个不太为人所知的 IPC 机制：Plumber，或者叫做管道工。我在”开发人员为何应该使用 Mac OS X 兼 OS X 小史“中曾赞扬过 Mac OS X 系统中的 AppleEvent 进程间通信机制对工作效率的提升。和AppleEvent 类似，管道工也是对图形界面下进程间通信的一个尝试，不过在通信的粒度上有所区别。

我们从一个简单的例子入手。在如今网络普及的时代，几乎所有的软件都能自动识别链接。只要打入 http:// 开头的一串字符，就立即转化为一个可点击的链接，点击这个链接则自动召唤出浏览器。我们对此毫不感到新鲜，因为这功能再自然不过。其实这些功能在上世纪９０年代还是很少见的。 Plan 9 的管道工，在当时就前瞻地提出一套匹配字符串和自动投递给指定应用程序的机制。我们只需要告诉管道工，用户选中字符串匹配某类型的时候就交由某应用程序处理，管道工即负责具体的程序间的通信。这是对 UNIX　管道机制的一个革新。如我在Mac OS 一文中所说，纯粹的管道机制在图形界面程序中已经不再适用了。

我们所熟悉的URI 处理仅限于浏览器，且只能处理由 RFC 2396 预先定义的 URI 模式。即便如此，我们也能体会到 URI 处理器的方便。像大家熟悉的电驴链接实际上是 ed2k:// 打头的 URI。在浏览器点击后就自动用电骡打开；苹果的 iTunes 的链接实际上是 itms: 打头的 URI；Android 商店的链接其实是 market:// 打头的 URI 等等，都是让用户更加方便的例子。有了这些机制后，我们难以想象没有这些机制而需要拷贝粘贴的日子是如何度过的。

管道工是 URI 处理器的推广形式。在管道工里，不仅仅是 URI，一切的字符串都可能匹配。因为读者可能没有用过管道工，我们仍然以大家熟悉的例子来说明。安装了 Skype 浏览器的插件会自动把网页上的电话号码变成一个特殊的“用 Skype 拨打该电话”的按钮，在 Gmail 里开启一些插件后 FedEx 和 UPS 的包裹号码能自动变成链接直接转到包裹查询网站等等。管道工的功能，就是让我们可以很方便的自定义这些转发功能，而不依赖于应用程序的实现。在 Plan 9 系统中，即使你不装 Skype, 不用 Gmail, 用户依然能够通过制定正则表达式匹配规则，来决定如何处理电话号码和包裹追踪号码等等。

管道工的原作者用编译器和编辑器的例子来说明管道工的作用。我们知道编译器报错语法错的时候，会以一定格式报出发生错误的文件和行号，如

Line 43: Hello.cc syntax error.

我们可以设定规则，在用户点击这些错误信息的时候，让管道工自动匹配和提取文件名，行号，并自动发给编辑器，就省却了我们人工打开编辑器跳到某行这个繁琐的步骤。尽管 IDE 已经通过集成编辑器和编译器的方式绕开了这种进程间通信，这种匹配/转发的通信方式仍然用在不少地方。比如 Vim 就引入了一个叫 errorformat (错误格式)的机制，让编辑器能够理解和匹配“错误格式”，并跳到指定的行。

通过 Plan 9 from user space 这个开源实现，我们可以在 Mac 和 Linux 上使用管道工。不过我们已经有了很多现成的工具能够部分实现管道工的功能。因为我日常只用浏览器和shell，因此简略介绍一下我是如何在浏览器和shell中实现类似于管道工的功能的。

用油猴子或者其他浏览器插件，我们可以将网页中某特定的字符串转变成一个定制的链接。然后，取决于所在平台，我们可以将这些链接和预定义的应用程序挂钩。Mac 下一个好用的工具是 RCDefaultApp ，Linux/Gnome 下的 gconftool-2　也直接支持对 URL-handler 的修改。Windows 下的方法则是修改注册表。（当然这些方法都有安全隐患，所以只适合个人使用）。

在终端里，对于 Linux 用户，urxvt 这个终端非常强大，可以使用 perl 扩展来匹配和执行命令，基本上可以完全实现管道工的这种匹配任意字符串且发送给其他程序的功能。在 Mac OS X 中，iTerm 2 是程序员应该用的终端。该终端目前还没有 urxvt 的强大扩展性，不过也能完成大部分匹配任务。比如说，iTerms 的最新版本支持一个叫做 Sementic History 的功能 (Preference -> Profile -> Advanced)。这个功能使得我们可以直接点击 Terminal 里面的文件名召唤出 Finder。用苹果的可能都知道 Mac 里有个 Proxy Icon （应用程序标题栏里面的小图标）的概念，我们可以直接把这个小图标当成文件的代表，拖来拖去，甚至可以直接拖到 Gmail 中当附件。我们其实可以把 iTerms 2 里面的文件名直接当成一个对象拖来拖去。

因为我日常只使用浏览器和终端，Plan 9 的管道工给我的启发是，如果有一套好的进程间通信机制，拷贝粘贴是完全没有必要的。如果你和我一样基本不用鼠标，并且认为拷贝粘贴是一个降低工作效率的事情，那么我建议你尝试一下用管道工的思想去改善你的工作流，看看哪些拷贝粘贴是可以由计算机完成的。

其实, 命令行的, 或者支持键盘工作的程序层出不穷，如果做个有心人, 每周几乎都能发现新的甩掉鼠标提高效率的工具。比如说，这一年中我就发现了如 keynav 这样使用纯键盘和二分法定位屏幕的程序，更多的支持 vim 键位的各种浏览器, 编辑器插件. 所有的这些工具, 用起来都非常酷(事实上不用鼠标本身就很酷). 因此，单从好用的工具来讲，”完全用命令行工作” 这个系列每月都可以写一篇. 一年过去了, 随着我更多的使用纯键盘工作, 我发现, 其实和用什么工具没多大关系, 掌握了一个基本原则之后, 那些工具顺手就可以找到.

什么是我想说的基本原则呢? 时隔一年, 我觉得可以总结成一句话: 鼠标更加容易分散注意力, 且输入带宽没有键盘大.

为什么说鼠标分散注意力呢?  我在“拔掉你的鼠标” 这篇文章中有过说明: 鼠标在屏幕上不受我们注意力的边界约束, 很容易使我们的注意力分散到各种地方, 成为工作效率的敌人。如果用时间管理眼光来看, 鼠标甚至可以说是时间管理的敌人 – 鼠标可以让你随时用一个窗口跳到另一个窗口, 一个关注点跳到另一个关注点, 使得你的时间规划失去效果.  我发现拔掉鼠标之后，上网不会乱点，无聊的时候不会点着好友的头像开始聊天，或者没事整磁盘碎片等等。拔掉鼠标的目的, 是为了提升工作效率. 当然我也知道, 拔掉鼠标是属于治标不治本的一种办法, 好在大部分浪费时间的应用都依赖于鼠标, 拔掉鼠标后想浪费时间也无从下手了. 所以在短时间之内的确算是一个提高效率的有效方法.

当然, 真正会把握自己时间的人, 是不会像上面提到的那样因为鼠标而分散注意力的. 即便这样, 鼠标也不见得有键盘好用. 用理论上来说, 鼠标这个“信息通道” 的带宽太小了，相比较于键盘, 鼠标向计算机传输同样的信息可能要花费更多的时间. 一个最简单的例子就是快捷键. 键盘快捷键不光比用鼠标在多级菜单中点来点去快, 甚至也比移动鼠标单击一个图标快. 究其原因, 还是因为鼠标操作图形界面是一种间接的给计算机发指令, 而用键盘快捷键相对直接一点. 只有在移动焦点和点击选择定位位置的时候, 鼠标才比键盘高效.

这一年, 我发现虽然还不能 100% 的抛弃鼠标, 但可以说 95% 的情况下, 鼠标的使用都是可以避免的. 具体来说, 包括以下几处.

第一, 消除浏览和寻找文件时对鼠标的使用, 用搜索来定位文件. 用鼠标定位文件的时候, 一般人会一层一层的打开文件夹直到找到所需的文件. 实际上, 应该使用桌面搜索(苹果自带) 去管理这些文件, 从而不需要用鼠标去点击文件夹. 除了桌面搜索, Quicksilver/Alfred 这样的启动器, 和命令行等等, 都可以节省在浏览文件上所耗费的鼠标点击和时间. 命令行也是一个大宝库, 很多时候, cp/mv 比拖放文件夹快多了.

第二, 消除窗口管理中对鼠标的使用, 用键盘快捷键代替鼠标点击按钮. 在多任务图形界面操作系统里, 我们常常需要移动, 最大最小化, 或者切换窗口. 如果有兴趣, 还可以尝试一下 Awesome 这样的平铺窗口管理器.

第三, 消除应用程序对鼠标的依赖, 使用快捷键. 几乎任何一个复杂一点的应用程序, 如 Firefox, Photoshop 或 Office , 都会提供一整套的快捷键方案. 相比较于用鼠标反复选择点击菜单项, 熟悉快捷键的人完全可以运指如飞, 手不离开键盘完成所有操作. 这也包括 vimperator 等让 Firefox 焕发第二春的杀手级插件.

当然, 我们用了好多年养成了用鼠标代替键盘的习惯，是不可能在一夜之间改回头的。如果你是一个用习惯了鼠标的人, 现在想要从鼠标转移到全键盘, 不要期望一会儿就能扔掉鼠标. 这个过程可能会持续几个月. 如果你上面的每一条都做到了, 就正儿八经拔掉鼠标, 工作个一星期. 几星期之后, 你会发现更多的快捷键, 更多的命令行工具, 写更多的脚本完成原来需要鼠标完成的事情. 到时候, 那就真的是 the world is your oyster 了. 你会发现, 原来计算机用起来是这么的爽, 而且再也不要担心腕关节受损了.

开发人员的趁手工具
对于开发人员来说，所有的开发工具的最大的用途，就是最大限度的提高开发人员的生产率 (productivity) 和创造力(creativity)。在我们这个时代，使用 GUI (图形界面) 是一个提高生产率的好手段。虽然上一代的那些 UNIX 开发人员的确不需要 GUI。一个屏幕，一个键盘，一个编辑器，在陋巷，人不堪其忧，也不改其乐的黑客比比皆是， 但二十多年过去了， 现如今开发环境发生了巨大的变化。 比如说，相比较于当年程序员使用的基于文本的环境，在 GUI 下格式丰富的文档显得更直观，阅读体验更加好；就算工作中不需要开发任何 GUI 程序，现代开发人员也会使用 GUI 来完成网页图片和文档阅览等等。 因此，即使是最传统的用命令行的开发人员，其实也能沾 GUI 的光。 比如说现在最好的终端程序，都是 X 下模拟的，因为这些模拟的终端的出现，一些复杂的可视化功能可以在这些终端中实现了，比如 Unicode 的显示(rxvt-unicode)等等。

对于开发人员，拥有一组非常好用的，能够最大程度的提高生产率的开发工具乃是一大人生梦想。那么，这套开发工具从何而来呢？ 大体来说，这些工具来自于三个方面： 1. 通过系统和单一的应用软件提供的；2. 通过搭配使用各种应用软件 3. 通过定制和改变现有的应用软件。 这三点，对于 UNIX 开发人员是再熟悉不过的了， 无非就是写脚本，走管道而已。 所以，在前 GUI 时代，这一套哲学非常盛行， 开发人员都知道，需要通过安装脚本解析器，写一些的脚本，配置一些环境等等，才能把刚出厂的 UNIX 系统，改造成自己使用起来得心应手的系统。 基本上任何一个使用 UNIX/Linux 系统多年的人，机器里面都有各种各样的“私藏”的脚本。离开了这些脚本，他的效率会大打折扣。

GUI 时代传统的丧失

上世纪 80年代的时候，GUI 时代和个人计算机普及的时代降临了。从此，计算机变成了个人电脑，历史上第一次，计算机不是专为开发人员设计，而是为了普通用户设计。普通用户的需求就是完成一个一个的现实问题，软件产业提供的解决办法就是为用户提供一个一个的应用软件，而不是让用户自己一行一行的编程和写脚本，巨大的软件需求瞬间成就了一个巨大的软件产业。 这样的一个间接后果就是，对于普通用户来说，让一台计算机变成能够帮助自己完成任务的“个人计算机”的唯一手段，就是叠床架屋的不断的装各种应用软件。

我们可以用一个简单的例子说明这种使用模式。 我们都知道，安装 Windows 系统的一个经验原则是把操作系统和应用程序分成两个逻辑盘，一个在 C 盘，一个在 D 盘。这个磁盘分区的经验原则不光网吧老板知道，连我大学里面只会点鼠标的那些女同学都知道。为什么有这个奇妙现象呢？其实，这是由 Windows 系统的用户的典型使用模式决定的。 在 Windows 系统上， 应用程序和文档是关键，操作系统只是一个随时可以重装的东西而已，所以干脆两者分开，互不影响。在这样的使用模式引导下，Windows 系统上格盘重装是非常低成本的，只要文档不丢，应用程序不丢就行。这种使用习惯，浪费了多少 geek 男美好的时光为人重装系统，又促成了多少美妙的姻缘 :)。 总之，在 GUI 时代，要解决一个问题，就装一个应用程序。至于应用程序之间的通信，和用非键盘鼠标的方法控制应用程序等等，都不再是要考虑的问题，有这样的需求的人成了非主流，非主流到以致于主流的操作系统和应用软件都不让你这么干了。 操作系统把所有其他的路都封死，就是明摆着告诉你，要想某样功能，请出门买软件。

Smalltalk 的启示

其实 GUI 时代原本不应该是这样的。 我们都知道，GUI 原本是施乐的 Alan Kay 那一帮人做科研做出来的，Bill Gates 和 Steve Jobs 各自到施乐”抄袭” 了一部分过来，于是窗口啊按钮啊就到处都是了。 他们都看到了图形界面和面向对象的形， 看到了图形界面就是把按钮图标等等对象放好，然后鼠标点击拖动等等这些表面的东西。 因为所有的 GUI 界面都是从文字界面起步的，所以所有的 GUI 程序，其实就是原来的可执行程序的包装。 C++ 这个语言的出现也很讨巧，把 C 包装成了一个面向对象的语言，包装对包装， C++ 很讨巧的适应了把可执行程序 GUI 化的趋势， 成了 GUI 时代的主流开发语言。从表面上看，只要运行这些可执行的程序，就能够看到图形界面，就能够用鼠标点击操作他们，可是这些东西的底层，都是一个编译过了的可执行程序，原先 Smalltalk 中的那些运行时环境啊，对象容器啊，都统统不见了，所有的图形界面程序，还是直接运行在计算机的 CPU 上，而不是一个虚拟的面向对象的容器上。而这个面向对象的容器（也叫做“运行时”或者“运行环境”），才是 Smalltalk 的神。 简单的说，Smalltalk 本身具有一个面向对象的运行时，所以即使到了执行的时候，里面所有的对象还是可以互联互通的。 而 C++ 写出来的程序，除了编译之前是面向对象外，只要一编译，就全部变成机器码，和对象就再也没有任何关系了，也就不存在运行时去动态的查看(inspect) 和改变(modify) 这些程序对象的说法。 总之，因为历史的局限，这些 GUI 的平台，都是渐进的照猫画虎的演变的，所以没有一个平台像 Smalltalk 那样细致地考量过对象的互相通信的问题，再加上我们上面说了，反正扩展系统的方法就是引入新的应用软件而已，本身也没有互联互通的需求，所以这种抛弃运行时的，不让对象被外部程序控制的实现方法也无所谓不好。

可是开发人员不是普通用户啊，他们依然要改造计算机成为自己的工具的。在现有的现有工具不能解决问题的时候，要不然自己重新发明轮子，要不然就复用现有的一些工具，或者重新按自己的需求重新配置这些工具。 所以，和一般用户不一样，开发人员需要这些 GUI 的可配置性，也需要这些 GUI 程序之间的互联互通。 用黑话来说，第一个问题关系到 GUI 应用程序的脚本化， 第二个问题关系到 GUI 程序之间的进程间通信。 这两个问题，说起来简单，但都牵扯到 GUI 系统的根本设计问题。 历史在这里开了一个不大不小的玩笑，把这个唯一的机会给了 Mac OS X。其他操作系统，都因为这样那样的原因，在这两个问题上没有很好的解决方案。

进程间通信，苹果的方案

花开两朵，各表一只。我们先说 GUI 程序的进程间通讯的问题。 所谓的进程间通信 （IPC），就是两个程序之间的信息共享。 我们都知道，*nix 的一个强大之处就在于管道，管道是最简单，最廉价也是最常用的 *nix 进程间通信的方法。在 GUI 时代，最常用的 IPC 机制成了剪切板和鼠标拖放操作。这两个操作虽然都很直观，但都要人操作，离开了人，程序根本无法自动完成进程间通信。 而要工作效率的提高，就是要让计算机离开了人的干涉，也能完成这些任务。为了自动化这些任务，操作系统就不能简单的绘制窗口然后万事大吉了，它必须要知道哪些程序在运行，哪个运行的程序可以给哪个程序发消息通信等等，比如说，如果我们想自动的在阅读器里面选择一个词送给字典程序查释义，计算机就需要知道字典程序在运行的时候可以接受一个字符串，但是不可以接受图片。如果我们把字典程序抽象成一个可以提供“查字典”服务的对象的话，毫无疑问，如果想要向字典程序发送字符，必须首先知道字典程序能够接受什么，用什么方式把这个单词发送给字典等等。 所有的这些信息，都必须由操作系统托管才行（不可能每个应用程序里面都要记着字典这个程序能接受字符串不能接受图片，这样每个应用程序都要记下所有其他可能的应用程序的信息，这是一个平方级别的关系，需要开发人员开发一个程序的时候还要兼顾其他所有程序，这显然是不现实的）。用行话来说，必须要有一个统一管理的运行环境，来管理这些程序之间的互相通信问题。 我们上面说了，Smalltalk 的神在于一个统一的面向对象的运行时，使得所有的应用程序能互联互通。 可是所有平台上的 GUI 程序的演化进程都没有走这条路，而是只把外表给模仿走了；有的平台即使想做互联互通，也做得不彻底（比如微软的 OLE，COM 等等）。

是好东西，总会发光的。 但是要想让这个好东西被新的操作系统全盘采纳，要想让一个系统能够从底层到上层全部采用统一的运行环境，就要扔掉很多的历史包袱。甩掉这种历史包袱，对于任何操作系统都是不容易的。如果我们回到当年，一定会幻想，要是有个神人，能够不管市场也不管现有平台，从头打造一个没有任何历史包袱的干净整洁的 GUI 系统该多好。 历史就是这么戏剧，还真就安排了一个人，做成了这件事情，这个人，就是那个斯蒂夫乔布斯。

1985 年，乔布斯被苹果扫地出门，成立了 Next 公司， 一心想要做出质量上乘的 GUI 计算机系统。 历史给了乔布斯一个全部从头做的机会。这一次，乔老师和 Next 的开发人员意识到，光照搬 Smalltalk 的形是不行的，要连它的神也拿过来，重头设计进程间通信和 GUI 系统。 在内核层面，他们用了 Mach 这个为 BSD 设计的微内核。 这个操作系统内核就是为了替换已经过时的 UNIX 内核而设计的，其中的一个核心设计哲学就是重新设计进程间通信； 虽然现在基于微内核的操作系统已经不是什么潮流（为此 Linus 和 Tanenbaum 吵了一场著名的架)，但在相比较于当时 UNIX 系统的内核（此时 Linux 还没出现的，UNIX 内核只有 BSD， Bell, SUN 等几套），Mach 算是一个高的起点。在这个内核上，Next 公司的工程师开始构建面向对象的基础系统。 这套系统在 Smalltalk 中已经有了蓝图，因此这些工程师以 Smalltalk 为蓝图，先设计了一套基于 C 的语言，也就是 Objective C，照搬了 Smalltalk 的经典的 [对象 消息: 参数] 语法。 (我个人不喜欢 Objective C 这个语言，Smalltalk 是一种纯面向对象的动态类型的语言，Next 公司当年完全有机会用 Smalltalk 语言的，如果用了 Smalltalk，现在的 Cocoa 框架还会更加漂亮，代码更加干净；用 Objective C 这个自创的语言，不知道是不是因为专利的考虑，反正 Objective C 这20年的所有创新，就是在慢慢的更像 Smalltalk 而已，Java 和 Ruby 这几年也是不断的从 Smalltalk 拿东西）。有了内核，有了语言，Next 构建了一个纯的面向对象的运行环境和类库（和 Java 和 .Net 的统一类库想法类似，只不过超前了十几年)， 这套类库，在当时叫做 NextStep, 所以所有的类名前面都带有 NS 前缀，无比丑陋。可惜的是，当年这个超越时代的类库太阳春白雪了，话说 Smalltalk 超越了时代 20年，所以90 年代中期的时候， 程序员才想起来当年 Smalltalk 的好，出现了 Java Ruby 等等受  Smalltalk 启发的语言。 乔老师虽然落后了 Smalltalk 5 年，却领先也业界 5-10 年，所以在 1995 年的时候， Windows 95 卖疯了， 乔老师的 NextStep 却没动静，只能把这个类库重新打包当成 Web 类库卖卖，即 WebObjects。这倒是无心插柳，生意不错，因为当时的 Web 开发已经吃尽了没有一个统一的运行环境的苦头（这也是日后 Java 风行的原因）。 我们说，是金子总要发光的，但是前提是要 (1) Next 再等几年，等业界回过神来认识到它的好处，(2) 获得一个主流的操作系统支持，把底层全换成乔老师的东西。 乔老师也知道这两个条件，所以加快了和 SUN 合作的步伐，想要把这套系统放到 SUN 的工作站上。 但是 SUN 本身有很强的底层技术，那段时间又狂推 Java, 所以其实乔老师在 SUN 这条路上胜算不大，况且 SUN 自己内核技术很强，所以肯定要肢解 NextStep 把内核重写，如果不和 SUN 玩，一来Next 这家公司能够多撑 5 年都是问题，二来几乎每家做个人计算机的公司都倒戈微软了，其他做工作站的公司又都有自己很强的底层技术，不可能用乔老师的玩意儿的，所以看起来乔老师和他的阳春白雪好像前景不妙。 可是天无绝人之路，放眼看当年的市场，只有一家公司没有倒戈微软，又没有很强的底层技术，又和乔老师有一些渊源，历史就是这么戏剧，这家公司就是把乔老师扫地出门的苹果。

90年代中期苹果的日子很不好过，个人电脑市场败给了 Wintel 联盟，新兴的市场上成绩也一塌糊涂，投资人也不糊涂，把当年让乔老师扫地出门的 Sculley 也扫地出门了，随后就把乔老师的公司给买了回来，让乔老师复职负责复兴苹果。 所以，上面我们说的两个条件就这样突然的满足了： 第一，他现在是老大了，所以可以彻底的把原来苹果的系统推倒重来，用自己的新家伙；第二，原来 Next 公司的那帮工程师不要担心失业了，现在由苹果负责发工资了，所以，正好可以让这些人着手改造苹果系统，主要的工作就是用自己带过来的新系统取代苹果的旧系统，并且让新系统的图形界面和旧系统保持风格的一致。 这个工作，从1995年 Next 被收购，到 2001 左右的时候才做好，这6年的时间里， 乔老师也顺带让苹果重新盈利了。

2001 年发布的 Mac OS X, 是苹果操作系统的第十代，完全基于了乔老师在 Next 开发出来的那套类库，所以自然的，具有了一个统一的面向对象的运行时。 这个运行时和类库系统，Mac OS X 把它叫做 Cocoa。其实 Mac OS X 刚出来的时候也不怎么好，不过依赖于这套设计精良的底层系统，Mac OS X 的迭代开发周期要比其他操作系统短多了 （仅慢于Linux, 不过 Linux 只有内核部分). 在短短的 8 年里，Mac OS X 就搞出了 7 次大的版本发布。 虽然我们看 Mac OS 好像从 10.0 到 10.6 只是次版本号在进步， 其实每次都是一个 major release, 大致相当于从 Window 95 到 Windows 98 或者 Windows 2000 到 Windows XP 这样级别的升级。 这样的发布却不改主版本号，一方面是从市场上考虑，另一方面也的确说明 OS X 的底层已经处于一个相对稳定的状态。 有很多 Windows 程序员非常推崇 .Net。 是的，.Net 的确是一个非常好的框架，可是想像一下，苹果在1995年的时候就有了一个统一的运行时，加上这么多年所有的程序都在这个统一的框架上开发，如果论在 Mac OS X 这个平台上的经验积累，应该说 Cocoa 社区是比 .Net 社区更加成熟的。

应用程序脚本化

光有进程间通信的系统还不能算是一个完全成熟的 GUI 系统，因为进程间通信依然是相对底层，而 GUI 上的应用软件是层出不穷的，不可能任何问题都跑到底层用进程间通信解决；所以，要想让 GUI 系统进化到易用和易于定制的水平，就需要开放对 GUI 程序的脚本控制。只有 GUI 程序能被外部控制了，才能真正的达到搭配使用 GUI 系统的效果。 其实，一旦有了一个统一的运行时，只要开发应用软件的时候统一设计一下脚本接口，用脚本控制 GUI 程序应该不难。 比如说，微软的 Office 系列套件， 就完全可以用 VBScript 去控制。 可惜的是，没有一个系统能够实现全系统的控制。 要实现全系统的控制，不仅仅要这个系统能够提供底层的支持，更重要的是要能说服所有的开发人员，或者说让所有的开发人员养成开放脚本接口的好习惯。 从技术上来说，这不是太大的问题，只要开发人员按照统一的脚本通信协议，实现特定的接口就行了，可是，如果一个平台上开发 GUI 的方法太多，开发人员只选自己喜欢的来，这种标准就不可能统一。 比如说 Linux 上 KDE 和 Gnome 都有自己的脚本化系统，可是开发人员有的用 KDE, 有的用 Gnome, 有的干脆两者都不用，这就谈不成有一致的接口。 一个平台要想有一致的脚本控制接口，除非 (1). 这个平台上就一种 GUI 开发方法，自古华山路一条，要不不做，做出来的东西就只能是标准的接口； (2). 这个平台上大部分的，主流的应用软件，都实现了这个脚本接口，这样因为这些程序的拉动，其他 GUI 程序想要融入这个平台上现有的应用软件的圈子相互通信，那也就必须要实现这个接口。 在 2000 年的时候，又只有一家公司能够同时满足这两个要求，就是苹果。 微软部分做到地了这两条，基本上用 VBA 统一了 Office 的控制，但是跳出 Office，微软的 OLE 对象模型几乎没有任何用武之地，与之捆绑密切的 VBA 自然无人问津。 不过据一些在金融行业工作的朋友说， VBA 能够大大提高 M$ Office 的生产率。

GUI 脚本化不是一夜之功，特别是我们说要做出统一的脚本接口，能兼顾各种程序的需求，这就完全不是一两年的时间能够搞定的，总需要很多年的技术积累和设计取舍后才能收敛到一个相对稳定成熟的系统， 而苹果，居然很神奇在十几年前就有这方面的经验，苹果再次怎么这么幸运呢？

在 80 年代后期的时候，苹果机上有一个非常超越时代的软件，叫做 Hypercard。 这个软件我曾经在上一代苹果上玩过，具体的思想就是你可以存储一张一张的“卡片”，这些卡片上面可以放置多媒体的声音，图像文字和其他对象，基本上就和现在网页一回事，唯一的区别就是这些卡片都存在本机。 在没有 Powerpoint 这类软件之前，这个 Hypercard 的软件可以用来做课件，做幻灯片演示等等，是个极其强大的工具。 为了让用户可以定制这个卡片，这个程序提供了一套非常强大的编程系统，叫做 Hypertalk。 因为这种编程语言是给普通人而不是程序员用的，所以你会感觉根本不是编程，而是写英语。这套东西，虽然本质上也是从 Smalltalk 学来的，但是用英语语法的方法编程的确是一个全新的思路，苹果把这个给普通人编程的语言发扬光大了，用更加贴近自然语言的方法重写了语言和文档，模仿 Hypertalk 系统，发布了一个跨系统的脚本控制语言，叫做 Applescript。这个语言就和自然语言没什么区别，比方说, 获取窗口的大小不再是
window.getSize()
而是
get size of window

显示第 22 段的 第一个单词不再是
print(paragraph[22].getWordByIndex[0])
而是
print the first word of paragraph 22

更狠的是，你还能用法语和日语写。 80年代后期的时候和整个 90年代初期，苹果基本上已经被 PC 机逼到墙角了，只剩下出版行业，设计行业等等专业的行业因为应用软件和图形处理能力的关系，依旧在守着苹果机。 两个行业的用户都需要自动化的 GUI 控制，但是编程都不怎么样，于是，这些应用软件的开发商也主动掺合加入 Applescript 旗下。 在90年代乔老师没有加入前，苹果自己把 Finder 全部脚本化，出版业的 QuarkXPress 和 Filemaker 也都完全脚本化，等乔老师入主苹果后，基于 Cocoa 的新技术，苹果一口气在 Mac OS X 上推出了 Safari, iTunes, iPhotos 等等软件，一股脑儿的全部脚本化了。 在别的公司都可望而不可求的历史机遇，又是被苹果给抓住了，一股脑儿全部塞进了 Mac OS X。这下，所有的第三方开发的工具，如 Firefox, Adium 这些，其实本来都不是苹果开发的，也没有太强的苹果渊源，但是 Firefox 要读 Safari 书签吧，哈，那就用 Applescript 吧，所以， Firefox 也逼着脚本化了（这个在其他平台上都不存在的事情）。 Adium 也是，这个聊天软件想要把 iTunes 正在播放的歌曲当成状态信息，好呀, Applescript，所以，也被带着脚本化了，而在 Linux 上的对应产品 pidgin 就没有这么脚本化。 所以，苹果平台已经成了一个惯性，你不想脚本化，就不带你玩，看你还脚本化不？

结语

我们都知道， UNIX 时代的主要哲学是提供给开发人员一组小巧精美且可以任意搭配使用的小工具，也就是所谓的 Software Tools, 然后任由开发人员由此出发，自己搭建自己的工具，打造自己的瑞士军刀。而开发人员所用的操作系统的目的，要不就是提供这样的一组开发工具，要不就是为这样的开发工具提供一个便利的平台，使得这样的工具变为可能。如果说 UNIX 是命令行时代的一个易于改造成 “自己的操作系统” 的操作系统的话， Mac OS X 就是 GUI 时代的这样的一个操作系统。 即使是从应用软件的层面看， Mac OS X 的底子好，更加容易出精品软件，所以即使仅使用应用软件，开发人员也应当优先考虑 Mac OS X。

附A: 相对正确的 Mac OS X 使用习惯

0. 一定要装 Quicksilver 或者用“服务”，否则就是把苹果当 Windows 用。
1. 在苹果计算机上，因为有服务和 Quicksilver 这样的工具，90% 的程序间的拷贝粘帖都是可以避免的。
2. 剩下的 10% 的程序内的拷贝粘帖，如果用一个好的编辑器的话，又可以省略掉 90%。

附B： 为什么 Linux 系统在这个方面还不够好

第一， Linux 上的 GUI 子系统，其实不是 Linux 的一部分，而是 X 和上面的 KDE 以及 Gnome
等等。 这几年，这些系统终于开始统一管理一个面向对象的运行环境了。可是这两个系统都是用C++ 所写，所以免不了费很大的力气才有了运行时信息，绕了一个大弯路，如果一开始这两个系统就用 Smalltalk 之类的有运行时的语言编写，至少现在应该有能和 Cocoa 抗衡的框架。

第二， 这几年 X 也认识到了在脚本化控制上面的不足，所以几年前做桌面的 Redhat 提出了 DBus 标准。 可惜的是不是每个程序都开放了 Dbus 接口，所以和苹果比起来，还有比较长的路要走。

在苹果下, 我用的 Launcher 自然是 Quicksilver. 在 Linux 下, 我一般是直接用命令行. 偶尔用用 GNOME Go, 不过基本上还是用命令行.

窗口管理器上, 我现在用的是 awesome windows manager. 这个窗口管理器支持多屏幕的纯键盘操作, 我强烈建议天天只用 Firefox 和一个编辑器一个命令行的程序员们尝试一下这个窗口管理器。 这个窗口管理器还有一个好处，就是所有的窗口控件都可以脚本化，所以，可以随意在状态栏加时间状态啊，按钮啊， 等等。 而且这些按钮啊，状态阿，都是可以在运行时用脚本修改的。比如你可以定时让状态栏闪动，只需要在 cron 脚本里面写一条就行了， 让控制闪动的脚本按时运行。

现在我聊天还是用 Freetalk. Freetalk 有一个非常好的特征，就是可以任意的加插件。 我写了一个插件，让我在工作的时候，除了爸妈，未婚妻或老板给我发消息触发一个“滴”，其他消息一概不响。这样非常集中精力。 有时候不得不上 MSN, 我就用 centerim 和 centerim-utf8 (后者支持汉字), 不过我极少用，一个主要原因就是我不知道怎么写插件。　这些不让我 hack 的软件基本上都不是太顺手的。

除了写程序和发邮件聊天，剩下的就是上网了。 自然，我上网是 Firefox。 我用了一个叫做 vimperator 的插件，可以纯键盘的用 vim 的方式控制 Firefox. 这个插件可配置性极强，基本上日常用到的翻页，开关标签和搜索，都可以一键完成。 如果您是 vim 的超级粉丝，这个插件肯定让你觉得上网冲浪从来没这么爽过。 以前我常常用 ubiquity, 不过现在鼠标被我拔了，所以”选中一段文字”这样的操作我基本不用，所以 ubiquity 用的相对少了。

还有就是看 pdf 了，我要推荐一个中国人开发的软件，叫做 apvlv。 这个软件可以让你用vim 的方式看 pdf. 比如光标往下走，直接按 j 就行了, 非常方便。 我现在看 pdf 基本上就用这个了， 每次文件另存为的时候只要 :w， 实在是大大提高效率。

最后，我在文本字符下面也发现了一个类似于 awesome 的咚咚, 叫做 screenwm. 这个软件, 可以让你横着或者竖着切分屏幕成任意的组合， 在每一个小单元里面，相当于运行着一个 GNU Screen 窗口。　所以，在我的宽屏上，我的左边是　vim，　右上面是　mutt/gtalk/todo，　右下面是 shell，　工作起来不要反复切窗口，　非常舒服。

如果您有什么完全用键盘工作提高效率的妙招，不妨留言告诉我　：）

起因是最近我在写一系列的中文文章, 因为几乎没有数学公式, 而我又喜欢纯文本的工作方式, 因此在排版上我选择了reStructuredText. 一般来说, 英文文本我都是直接在 vim 下工作. 可是苹果下的 vim 对中文的支持不是想像的那么好, 至少中文输入法打出来的常常有乱码. 名动天下的 TextMate 固然好, 显示中文却只有半个字那么宽, 看上去很不舒服. 其他的编辑器要么收费, 要么嫌大, 要么不顺手, 因此落到最后还是用了苹果的 TextEdit.

但是写技术文章的人都知道, 写文章不仅是打字这么简单. 特别是技术文章, 常常需要离开编辑环境跑脚本, 查Google, 看 wiki. (我不知道别人是不是这样, 至少我为了写出质量较好的文章, 写的时候也要做很多功课). 特别是因为我在用 reStructuredText, 一个最基本的需求就是处理当前文本生成 HTML/LaTeX 然后预览. 这些需求, 在 VIM 和 TextMate 中都是原生支持的, 很简单能做到. 但是在 TextEdit 这样的软件中, 乍一看, 毫无办法. 所幸的是, UNIX 家族的操作系统, 特别是苹果, 秉承了 简单的事情要有简单的解法, 复杂的事情要有可能的解法 这样的设计思路, 提供了不止一条解决问题的方法. 因为苹果设计了一个叫做”脚本化应用程序”的东西, 使得这些任务可以很简单的完成. 我研究了几天, 学到了一些东西, 拿出来和大家分享.

1. 最常常被忽略的菜单栏, Service 菜单.

用具体的例子来说可能更加简单. 用 Gmail 的各位都知道, 如果邮件里面有 90081243455 这样的数字串, 或者有 北京是西城区XX路YY号 这样的地址, Gmail 就很贴心的显示出 “使用 Google 追踪快递包裹” 或者 “使用地图查看地址” 这样的链接. 也就是说, Gmail 会识别出这些特定的样式, 然后给你一个上下文相关的(也就是说, 和你内容相关的) 服务. 这样的服务贴心舒适, 相信不少人都很喜欢. 一般我们把这个叫做上下文相关的服务.

再说 Firefox. 前不久 Firefox 出了一个很贴心的小插件, 叫做 Ubiquity, 我在 Firefox 下几乎离不开它: 选中任何一行地址, 只需要敲几个键, 就可以查 Google Map. 选中任何一个名词, 可以立即查 Wikipedia, 等等. 一般我们把也把这个叫做基于选定的服务.

苹果上的 Service 菜单, 就是这样的一个基于上下文相关和基于选定的服务. 举个最简单的例子, 如果你的机器上装有 Skype, 然后你选中了一串电话号码, 这时候你可以到 Service 菜单中选择 Skype -> Call this number. Skype 就会自动拨打这个电话. 或者选中一个单词, Service 菜单中就会自动出现: Look up in the Dictionary. 选中它以后, 你机器上的字典就会跳出来, 把单词的释义呈现给你. 所有的这一切, 都是基于苹果的一个叫做 System Service 的框架. 简单的说, 每个应用程序告诉系统: 在什么情况下, 你给我什么信息, 就可以让我做什么事情. 这样, 在选定的上下文符合条件的时候, 你就可以在菜单中选择这个服务. 这个东西方便无比. 比如说, 常常老板在邮件里面写: 你这周做啥啥. 我就可以选中整行句子, 按下 ⇧⌘ Y. 这样整行句子就被纪录到 Stickies 里面去了, 相当于随时写下一个便签.

现有的菜单栏固然好, 但是自己编写的更加好玩. 所幸的是, 你不需要会苹果的生涩的 Obj-C 才能编写菜单. 有一个强大的工具, 叫做 ThisService, 能够把 Ruby, Python, Applescript 和 shell 脚本都包装成 Services. 比如说我昨天就花了一分钟写了一个很简单的叫做 Translate 的脚本, 通过 Python 提交文本给 Google Translate, 返回中文. 在阅读有很多不认识的单词的新闻文章时候, 只要选中段落, 选择这个 Translate. 一个翻译成中文的窗口就出现了. 在这个软件的帮助下, 任何脚本都能点一下鼠标就变成一个服务: 具体我就不一一详述了.

总的来说, 我们可以注意到, 在日常使用计算机的时候, 一个应用程序中的一些内容(文本或者图像), 往往要作为另外一个程序的输入, 交给另外一个程序处理. 比如选中的单词查字典, 选中的地址查阅地图, 和选中的电话号码拨打, 选中的句子翻译等等, 这些需求都是存在的. Windows 家族解决问题的方法, 是通过程序切换和剪切板. 而苹果就是通过统一的接口来完成的, 思想和UNIX管道是非常相似一脉相承的 (当然, windows 家族从来就没有 UNIX 家族管道这个思想, 所以也就想不出统一接口这样的设计了).

在苹果下, 统一脚本接口可以用来处理像 Service 这样的程序之间通信的问题, 这个是 windows 家族从来没有想过的. 同时, 据我个人经验, 这个思想在 Linux/X11 家族也没有全部实现. 在 Linux 命令行下, 我们都知道, 不同的小工具之间是正交的, 一个程序的输出是一个程序的输入, 这个 UNIX 哲学长盛不衰. 直到今天, 正常的 Linux/UNIX 用户也会天天用管道做程序之间的通信. 可是在图形界面出现后, 这样的好传统在 X11 系统中似乎没有被继承. 比如, 不能选中一段文字直接送给 wc 计算字数. 究其原因, 是因为图形界面再也没有明显的输入输出这个概念了. 字符串和图像变成了要在程序之间传送的基本单位. 在这种情况下, 就需要不仅仅以文件为基本单位, 而是以被选中的那些字符串, 句子, 链接, 图片等为基本单位的通信. 在这个层面上, 苹果的确先行一步. (当然 Emacs VIM 等等也是可以通信和调用外部程序的, 但是毕竟不是整个系统都能这样).

2. 史上最简单的语言, AppleScript.

故老相传, 当年 Knuth 大神访问苹果, 总裁 乔布斯 同学发挥爱吹牛的光荣传统, 说: 高教授, 您来了. 我特别崇拜你, 您的书我都读过. 各位读者都知道, 要是Jobs 真的把高教授的书都读过, 全世界大学计算机系99%的教授基本上都要自杀让位给Jobs. 所以, 高爷子知道他吹牛皮. 以下的故事分两个版本, 第一个版本是硅谷的版本, 是高爷子当即就说: 斯蒂夫同学, 你又扯淡忽悠了. 第二个版本是我的版本: 说高爷子一听, 也不生气, 心想, 你我共同作为硅谷两个最懂字体设计的搞IT的, 我也不好得罪你, 且问你一道简单的问题, 看你读了我哪几本书. 于是高爷子眼珠一转, 题上心来, 问到: 乔布斯同学, 请问世界上最简单的编程语言是啥子呢? 乔布斯是个不懂技术的主. 想起当年和 Woz 合作的时候搞的东西叫做 BASIC, 听名字就觉得简单, 于是说道: 乃是 BASIC. 高爷爷说, 还有比这个更简单的么. (话说高爷爷心想, 我手里握着 TeX, Metafont, MIX, Literate Programming, CWEB 等几张王牌, 我就不信你说不出一个搭不上边的). 乔布斯同学哪能体会到高爷爷的良苦用心, 他又不会编程, 于是就杜撰到: 我们公司最近正在开发世界上最简单的一个语言: 叫做苹果脚本(AppleScript). 高爷爷一听就知道又是吹牛, 于是立即回复: 斯蒂夫, 你又扯淡忽悠了. 斯蒂夫同学哪服软, 于是要求开发部门开发一个连他都懂怎么用的语言. 于是 AppleScript 就被捣鼓出来了.
(以上故事纯属扯淡忽悠)

话说AppleScript 有多简单呢? 就和说话一样简单. 我曾经也写过介绍. 再这里再给一个例子:


tell application "TextEdit"
set filename to name of document 1
print filename
end tell


看, 明明就是英语嘛! 这么平铺直叙几乎没有语法的编程语言, 真的是世界上最简单的编程语言唉.

别看这个语言简单, 威力可不小. Mac 上几乎所有的应用程序, 都能够用这个语言去控制, 特别是 iTunes 甚至还有一个专门的网站, 专门就让你下载千奇百怪的控制脚本.

Applescript 还有两个好处: 1. 他是苹果原生支持的, 可以直接编译成苹果的应用程序来用. 因此, 简单的任务处理都可以用这个语言. 比如我们上面说的做成 Service 的, 也可以用 Applescript 来实现. 2. 他能够和其他应用程序交互. 其实在苹果系统中, 在脚本桥技术(Script Bridging) 出现之后, 理论上C/Javascript/Python/Ruby 都是可以和应用程序交互的. 可是AppleScript 的支持更加好, 更加直接. 比如取当前播放的iTunes乐曲名字, 可以用
AppleScript:

tell application "iTunes" to get the name of the current track

也可以用 Python

from Foundation import *
from ScriptingBridge import *
iTunes = SBApplication.applicationWithBundleIdentifier_("com.apple.iTunes")
print iTunes.currentTrack().name()

显然 Python 要显得笨重一些.

同时, AppleScript 也是苹果中小机器人 Otto 的底层技术, 因此在整个系统中发挥了基础性的作用. 虽然学习 AppleScript 显得很偏很不入流, 但是在苹果上做一些小任务有时候还是用得着的. 比如说我的让 TextEdit 支持 ⇧⌘ R 自动编译的例子, 就是先写了一串脚本, 取当前文件名, 然后使用 do shell script 这个指令调用 make. 这样, 调用这个脚本, 就可以完成自动编译. 用快捷键来调用脚本, 有两种方式, 一种是通过把脚本拷贝到应用程序的脚本目录并且添加一个菜单项. 另一种是用 QuickSilver 来帮忙了. 第一种方法应该最简单, 但是我没有尝试成功, 有兴趣的读者可以读这篇文章.

3. QuickSilver

我曾经间或的提到过 QuickSilver. 刚开始我并不能体会到他的魔力, 直到最近在玩脚本控制的时候才发现. 简单的说, QuickSilver 就是能让你用键盘控制程序的程序. 或者说, QuickSilver 就是键盘命令中枢. 比如说播放音乐, 只要一键激活 QuickSilver, 再打一下 play (有时都不要打全), 回车. iTunes 就放起音乐了. 上面我们说的任何控制系统的脚本, 都能够被 QuickSilver 控制. 我在拔掉你的鼠标一文中也提到, “你要是苹果用户又不用QuickSilver或命令行, 那你是把苹果当Windows用”.

QuickSilver 作为应用程序快速启动的功能大家想必都很熟悉. 控制 iTunes 大家也得心应手. 我就介绍一个被大家忽略的功能: 设置上下文相关的快捷键. 传统上, 快捷键是被应用程序定死的. 即使你写了一个扩展应用程序的脚本, 你也得点点鼠标去调用, 而不能设置键盘快捷键去调用. 解决的方法有三个, 第一个是我在第一部分讲的, 包装成一个 Service. 这样的好处是可以包装出一个快捷键, 坏处是这个Service 是全局都有用的, 不管你在哪个应用程序里面, 这个 service 都能用. 第二种是我在第二部分提到的我没有尝试成功的, 即添加一个菜单项目的方法. 第三个就是采用 QuickSilver 的 Trigger 功能了. QS 用户可以使用 ⌘’ 调出 trigger, 然后添加一个 Custom Trigger, 把目标指向自己写好的一个 AppleScript, 给这个 trigger 分配一个快捷键, 并且把使用的范围 scope 限定在一些应用程序中. 这样, 不费任何功夫, 只写一个简单的脚本, 您就可以在你的计算机上把你的 TextEdit 也改造成一个功能强大的编辑器了.

结语: 如我在拔掉你的鼠标一文中说的, 完全使用键盘能强迫人使用高效简洁和正确的工具. 随着图形界面和多媒体的出现, 鼠标的反而成了一个最常见的动作. 其实认真分析鼠标点选操作就发现, 无非是两种: 一种是用鼠标选择内容, 准备用一定的工具和程序处理这个内容, 还有一种是鼠标选择操作. 前者对内容的选择, 鼠标是高效的. 而后者对操作的选择, 鼠标是低效的 (因为键盘快捷键和命令行更加高效). 因此, 如果我们想要高效的工作, 就要避免后一种操作, 并且进一步解放前者.

对后一种的避免很简单: 拔掉鼠标, 强迫用键盘. 对前者的解放, 随着各种各样如 Service, Ubiquity 以及上下文敏感程序的兴起, 使得我们不需要在不同的程序之间拷贝来拷贝去, 而是直接通过程序之间的标准接口通信, 使得我们甚至不需要切换程序. 所有的都应该这些基于命令行和后台来完成, 而不是通过分散注意力切换程序来完成. 这些新的工具, 更加符合一个高效能的现代人的需求, 更加能够提升你的效率. 当然, 决定做事的效率的不仅仅是工具, 因此, 不要迷恋这些工具. 为了获得 1% 效率的提升, 而过于强调工具的各种淫巧, 反而降低效率. (警告: 这些工具都是非常迷人的, 很容易一用就爱上它们. 记住, 效率是最好的判断标准 :).

附 “完全用命令行工作系列” 文章一共五篇, 写了也不少了, 有些工具我一笔带过, 有些我花了几句话讲了一下. 基本上我介绍到的提到的, 都是我自己天天用的, 也是我认为非常有用的. 我写作的时候也都是带着 “Smart and Get Things Done” 的哲学, 只介绍干净的设计良好的软件. 各位想实践 GTD 的读者可以自行选择趁手工具. 有更多的 GTD 的完全用 键盘/命令行 工作的软件, 也不妨向我推荐.

完全用命令行工作-3: 常用工具

完全用命令行工作-2: 常用软件

完全用命令行工作-1: 拔掉你的鼠标

完全用命令行工作: 几条趁手语句

Linux 本身只是一个内核, 所谓的内核, 就是你看不见摸不着的东西. 平时打交道的, 都是应用软件和一些常用的命令. 很多人说学习Linux, 实际上学习的是这些常用命令和软件的用法. 这些知识, 其实不光是Linux 上通用, 在苹果, Solaris, BSD 等系统上都是通用的.

同时, 只有学会了这些应用软件, 才能随心所欲的驾驭计算机. 否则, Linux 系统的魔力就体现不出来. 有一种观点说: 反正是完成工作, Windows 高效就用 Windows. 而实际上, 如果对 Linux 上常用应用软件稍做一些探索, 就可以发现, 大部分日常工作都是用 Linux 系统上的软件高效, 因为他们从一开始就比 Windows 设计优良. (当然, 我依旧承认在多媒体方面 Windows 上的软件如 Photoshop 等专业软件的确比 Linux 上的对应软件要强大. 但是这个强大是 Adobe 的软件, 不是微软的操作系统 ).

下文就是介绍 Linux 上高效工作的一些常用软件.

GNU coreutils: 很多人学 Linux, 其实就是学这里面的命令. 比如 cat, ls, head, kill,  这些都是一个基本系统必备的工具集合. 学会了这个里面的命令, 基本上任何 *nix 系统能搞掂. 比如你以后用苹果Mac 也好, unix 服务器也罢, SUN 的Solaris 也行, 都是一样的用法. 而且这里面的工具的确很强大, 比如以前我说的求集合的交集和差集, 就是这里面的小工具拼一下就出来了.

GNU findutils: 这个工具包能够帮助你在 Linux 系统上找文件, 或者对满足一定条件的文件做一定的操作. 其中的 find 和 xargs, 可以变化出无数组合, 让对文件的批量处理变得异常简单. 比如说, 把当前目录及其子目录下面所有的早于2002年的照片文件都删除这样一个操作, 在 Linux 下面就是一行命令, 而在 Windows 底下就要求助于专门的照片管理软件了.

cron: 假如你想每天定时让你的计算机做一件事情(比如, 控制电饭锅做饭), 或者每个周日的晚上帮你把文件清理清理, 或者每天早晨给你抓取各大网站的新闻存成摘要投递到你的桌面上, 你肯定需要 cron 这样一个强大的东西. 他的使用出乎想象的简单, 就在一个指定的文件里面写上什么时间做什么就行了, 比设置 Made In China 的闹钟还简单. 这个定时做事情带来的效率提醒是意想不到的.

screen: 如果你登录到一个机器工作, 退出的时候还想保持命令行继续存在, 下次登录还能继续工作, 或者你想和另一个人同时在一个命令行界面里操作, 或者你想只登录一次, 却拥有多个可用的终端窗口用来工作, 那么恭喜你, screen 是你想要的. screen 可以帮助你模拟出多个输入, 并且方面的切换, 还能把终端挂起来, 下次连上去继续工作, 这个对于在远程服务器上工作的人是杀手工具.

expect: 如果你非常讨厌每次登录telnet 的时候都要输入一次用户名密码, 如果你每次用某些软件的时候都要千篇一律的输入很多东西; 如果你想挂机刷机赚经验, 如果你想测试你的程序是不是正常工作, 那么, expect 是一定要使用的. expect 本来是用来做程序测试的, 看程序是不是有预想的输出. 有创意的玩家把他用去自动上论坛挂机或者自动登录FTP了. 如果想要自动化一些在命令行下交互性质的事情, expect 是很好的选择. 而且, 学习一下, 估计也就10分钟.

wget/curl: 支持多线程通配符递归, 断点续传等一切迅雷有的功能的下载器, 而且没有烦人的小广告. 如果要常常下载东西, 这个比迅雷好玩多了.

make: 以上说的都是单个工具. 而这个make 就是把工具组合起来的. 比如说, 写一个报告可能涉及画插图, 写文字, 生成报表, 做排版. 这些任务之间有依赖关系, 比如报表依赖于数据, 插图依赖于一个脚本, 排版依赖于一个格式规定. 数据更新了, 报表就要更新. 所有的这些任务和任务的依赖关系, 都可以写一个简单的makefile, 这样 make 就可以托管了. 假如数据更新了, 生成报表的时候只要重做报表, 插图就不需要重做. make 能自动分析这些依赖关系, 使得只执行必要的任务, 极大的减少了人工管理的负担. 事实上, 我的论文和家庭作业报告基本都是用 make 管理的.

convert/display: 这是使用 Linux 做日常工作的人必然要碰到的两个程序. 简单的说, 这是两个无所不能的程序. 其中 convert 能把一切能显示的图像格式转化成另一个格式. 比如png 和 pdf 之间的转化, 就是一句话. 而display 则是显示一切能现实的. 这两个, 还有其他的一些程序,  都属于ImageMagik 这个包. 用多了, 就会感叹, 其实把图片加加对比改改大小或者旋转旋转这些事情, 就是一行命令, 完全不需要开一个窗口点鼠标. ImageMagik 的设计也充分体现了 Facet 的设计模式, 接口非常简单, 自然, 常常和图片打交道的人熟悉使用以后, 效率能成倍提高.

另外, 学会正则表达式和一种脚本语言是必须的步骤. 其实这些都不是想象的那么难, 只不过是换一种眼光看问题罢了.

总的来说, 就一点: 在使用计算机做一件事情前, 先想想, 我是不是聪明到是世界上第一个遇到这个问题的人. 如果不是, 就动脑筋想想这个事情是不是可以分成几件小的步骤, 这些小的步骤是不是有现成的工具了. 一般情况下 99% 的都有前人的软件. 如果实在没有, 自己就开始写一个. 通常来说, Linux 比 Windows 效率高的所在, 在于工具的高效配合, 而不是直接找到一个包打四方的巨无霸的工具.

(本文覆盖肯定不全, 欢迎留言补充)

我觉得, 工作效率低下的原因很简单: 精力没有集中. 在计算机前工作的时候, 我发现一个提高精力集中度的最好办法: 拔掉鼠标.

拔掉鼠标意味着上网的时候不到处乱点链接, 书写的时候不简单的拷贝粘帖以及不会先想着格式和排版以干扰思路, 阅读的时候不动个不停的指向正在读的词(很差的阅读习惯), , 编程的时候不会老拷贝粘帖而是使用重构, 打开应用程序的时候不会误点到魔兽, 无聊的时候不会在联系人列表上找个人就随便海侃. 总之, 做一件事情的时候被限制在当前的窗口中, 注意力必然会提升. 具体来说, 不用鼠标意味着只用键盘来操作应用程序, 优点至少有以下几个.

1. 做正事时, 完全使用键盘能强迫人使用高效简洁和正确的工具. 我认为, 现在大多数应用程序都是堆砌一辈子用不到的功能, 而不是直截了当的解决问题. 那些工具窗口, 菜单栏, 状态栏等等到处都是, 想要完成一个任务必须在很多的工具中选择一个按钮点击. 其实选择和点击按钮只是完成操作的手段而已, 而不是必须步骤. 假如能够直接告诉计算机我想要做什么, 而不是先翻译成”我要点这个你才能做什么”, 效率会高很多. 而命令行就是直截了当的解决方法, 通常老手会选择使用快捷键, 这比点鼠标速度要快, 效率要高. 其实一般的应用程序, 核心功能不会超过20个, 这样20个核心功能用键盘操作完全有可能. 我甚至认为, 不能用键盘完全控制功能的程序, 可能本身就是不够简洁的. 使用这样的工具, 可能本身就是一个错误.

2. 处理零碎任务时, 使用命令行效率比鼠标点击简洁高效. 这是我观察到的一个具体的例子, 我想要看2009年1月4日是星期几, 在图形界面下, 我需要点击日历, 通过下拉选择2009 和 01 这两个选项, 然后才能看到日历. 鼠标输入2009和01是很费事的事情, 而在命令行下面我只要 cal 1 2009 就可以直接看到日历. 命令行能够直指问题本身, 绕开不良窗口界面设计造成的很多操作负担. 再比如说, 在使用网上日历和提醒的时候, 一句”have lunch tomorrow at 12:00pm with X” 显然要比用鼠标一个一个选择日期, 时间, 地点和事件来得直接. 在这方面, Gtalk 有很多的机器人可供大家选用, 比如查字典, 直接给字典机器人发送一个单词就能获得翻译, 比点一下字典程序等着启动然后输入单词要快太多了. 所有的这些目的性明确的小任务, 耽误的时间都不应该超过10秒钟. 如果使用命令行, 这个时间可以继续减少, 而使用鼠标点来点去, 至少要30秒. 而日常的零碎事务往往全是这类. (比如写一行备忘, 发一个小文件, 加一个提醒, 查一个单词或者维基, 标记一个日历, 控制一个远程服务等等).

3. 完全使用命令行, 使得浏览网页和无聊闲逛的时候注意力也集中. 我观察自己发现, 在电脑前面最浪费时间的事情就是顺着一个有趣链接点下去, 无穷无尽. 看上去获取了很多信息, 其实过眼即忘. 聊天也是, 往往一个爱说话的哥们上线聊上了, 一晃时间就过去好大一会儿了. 而完全使用命令行, 就强迫自己得用无穷多次的Tab才能点击那些链接. 这样, 就不会去主动点击那些链接. 聊天的时候也一样, 在命令行下面的会话没表情没声音也没提醒, 上线也没提醒, 干扰少很多.

再说我自己的具体的实现方法

1. 邮件和日常事务

Gmail 网络效率也不完全高. 最好用 Mutt. 快速发送文件附件的情况下 Mutt 是瑞士军刀, 参见我以前的叙述. 编程和文本编辑器随便是vim, emacs 都用不着鼠标的, 而且效率高. 浏览器一般使用 elinks, 遇到非Ajax 不可的才搬出 Firefox. 排版和做演示都使用LaTeX, 这个大家做科研的都知道. 另外, 把一些日常要做的任务写成make 脚本, 效率的提高是超出想象的.

2. 零碎小事

日常事务可借助形形色色的 Gtalk 机器人, 以及 Twitter 上一些特别的机器人. 其中Gtalk 客户端最好使用 GNU Freetalk, 可以自定义钩子(使用史上最优雅的 LISP 语言噢). 从而可以通过解析 Gtalk 消息调用系统程序. 比如我家有一台破电脑, 一直挂着Gtalk, 我在学校要回家之前就可以给这个Gtalk 发送信息让他提前打开我们家的空调或者电灯. 这些零碎的小事情的处理在 Web 背景下特别好解决. 如果你不是深度网络用户, 使用shell 脚本也能完成大多数工作. 比如日历, Linux 下面的日历管理工具都是支持命令行的. 其他如提醒啊, 日记啊, 字典啊, 都有工具. 除此之外, sed/awk, wget/curl 等等都有想不到的妙用, 完全可以把日常事务中的零碎小事处理得井井有条 (要知道, 当年贝尔实验室的科学家们就仅用这些工具辅助炸药奖研究的, 当时候微软还在做DOS呢).

如果你是Firefox 用户, 最近的一个 Ubiquity 的确是杀手级别的应用. 除了能控制网络服务外, 你也可以自己写个脚本, 把消息转解析到本机端口, 本机开一个简单的HTTP服务把消息代理给其他应用程序, 这样, 理论上, 在Firefox 里面也能控制整个计算机. 我也尝试了在学校Firefox里面控制我家的空调, 看上去很酷. 苹果用户也有福气, QuickSilver 这样的杀手级程序早就红遍大江南北, 我就不多说了(你要是苹果用户又不用QuickSilver或命令行, 那你真是把苹果当Windows用了, 暴殄天物啊!)

虽然没有严格的证明说鼠标一定浪费时间, 但是浪费时间的应用通常都需要鼠标支持. 我因为鼠标坏了舍不得买, 无意发现了这个结论. 如果你不相信我说的, 不妨尝试一下强迫自己不用鼠标一天, 看看自己是不是浪费的时间少了很多.

[点击可看大图]

我写了一个 AppleScript, 可以读 iTunes 正在播放歌曲的歌词.

set notify to "Not playing"
tell application "iTunes"
	if player state is playing then
		set who to artist of current track as string
		set what to name of current track as string
		set lyric to lyrics of current track as string
		set notify to who & " : " & what & (ASCII character of 10) & lyric
	end if
end tell
set notify to replace_chars(notify, ASCII character of 13, ASCII character of 10)
notify

on replace_chars(this_text, search_string, replacement_string)
	set AppleScript's text item delimiters to the search_string
	set the item_list to every text item of this_text
	set AppleScript's text item delimiters to the replacement_string
	set this_text to the item_list as string
	set AppleScript's text item delimiters to ""
	return this_text
end replace_chars

然后写一个 Shell 脚本, 去调用这个 AppleScript:

#!/bin/bashif [[ -n `ps x | grep "iTunes -psn" | grep -v grep` ]]; then
  osascript ~/bin/itunes-playing.scpt
else
  echo "iTunes off"
fi

最后, 在 Geektool 中设置运行这个脚本就行了.

本文主要参考这篇文章, 脚本除了歌词部分, 其他都是一样的. 就是歌词折腾了我好久, 原来 Mac 底下换行是 \r, 这样输出到 Shell 就不正确了. (可以尝试一下 printf(“abc\rdef”) 就知道为什么了). 最后把输出重定向到文件再用 VIM 才发现全是 ^M. 其实我也考虑到了这个问题, 在程序中替换 “\r”, 只是苹果的 Script Editor 很变态, 每次我敲 “\r” 都自动换成一个换行, 因此费了好大力气, 找到了一个 ASCII character of 10. 说实话, 从来没见过这么平铺直叙的脚本语言…

大家用苹果吧 ;)