实用程序喜欢生活在管道中。管道允许实用程序专注于自己的工作，而不是去关注旁枝末节。为了生活在管道中，实用程序需要从标准输入读取数据，然后向标准输出写出数据。如果您希望处理记录，那么您最好能够使每一行成为一个“记录”。诸如 sort 和 join 之类的现有程序已经在那样考虑了。它们将会因为您这样做而感谢您。
我偶尔使用这样一个实用程序，它针对一个文件树反复调用其他程序。这充分利用了标准的 UNIX 实用程序过滤器模型，但是该模型仅适用于读取输入然后写出输出的实用程序；不能将它用于就地操作或接受输入输出文件名的实用程序。
可以使用标准输入来运行的大多数程序也完全可以针对单个文件或一组文件运行。注意，可以证明这样违背了反对重复工作的规则；显而易见，这可以通过将 cat 的输出馈送给该系列中的下一个程序来解决。然而这在实践中似乎是合理的。
有些程序可能合法地读取一种格式的记录，但是却产生完全不同的输出。这样的一个例子就是将输入材料划分为列的实用程序。这样一个实用程序可能将输入中的行视为记录，但是却在输出中的每行上产生多个记录。
并非每个实用程序都完全符合这个模型。例如，xargs 不是接受记录而是接受文件名作为输入，并且所有的实际处理都是由其他程序完成的。
通用化
尝试将任务看作与您实际执行的任务类似；如果您能找出这些任务的通用描述，那么最好尝试编写一个符合该描述的实用程序。例如，如果您发现自己一天在根据词法对文本排序，而另一天在根据数字对文本排序，那么考虑编写一个通用排序实用程序也许是有意义的。
对功能进行通用化有时会导致您发现：某个看起来似乎像单个实用程序的程序，实际上却是配合起来使用的两个实用程序。这很好。编写两个设计良好的实用程序可能要比编写一个丑陋的或复杂的实用程序更容易。
做好一件事情并不意味着 仅仅 做一件事情。它意味着处理一致但有用的问题空间。许多人都使用 grep。然而，它的大量效用在于执行相关任务的能力。grep 的各种选项完成许多小实用程序的工作，如果这些工作都由单独的小实用程序来完成，最终会造成大量共享的、重复的代码。
这条规则，以及做好一件事情的规则，都是一个根本原理的必然结果：无论何时都要尽可能避免代码重复。如果您编写半打程序，其中每个都对行排序，您最终可能必须六次修复六个类似的 bug，而不是去使用一个得到更好维护的 sort 程序。
这是编写实用程序的一部分，即把大多数工作添加到完成该实用程序的过程中。您也许没有时间在最初就完全通用化一个实用程序，但是当您一直使用该实用程序就会获得相应的回报。
有时，向某个程序添加相关功能是很有用的，即使这个功能并不是用来完成完全相同的任务。例如，当运行在终端设备上时，对原始二进制数据进行完美打印的程序可能更为有用，因为它使终端进入原始模式。这样使得测试涉及键盘映射、新键盘等的问题变得容易多了。不确定为什么当您按 delete 键时却得到代字号（~）吗？ 这是弄清实际发送了什么内容的容易途径。这并不是完全相同的任务，但它足够类似，因而可能成为一个附加特性。
清单 2 中的 errno 实用程序就是通用化的很好例子，因为它同时支持数字和符号名称。
健壮
实用程序的稳定性是很重要的。容易崩溃或无法处理真实数据的实用程序不是有用的实用程序。实用程序应该能够处理任意长度的行、巨型文件，等等。实用程序无法处理超过其内存容量的数据集或许是可以容忍的，但是有些实用程序不是这样；例如，sort 通过使用临时文件，一般能够对比其内存容量大得多的数据集排序。
应该尽量确保弄清楚您的实用程序可能要操作哪些数据。不要简单地忽略无法处理的数据的可能性。应该检查这种情况并诊断您的实用程序。错误消息越明确，您对用户就越有帮助。尽量给用户提供足够的信息，以便让他们知道发生了什么情况以及如何解决。当处理数据文件时，尽量准确识别出不良的数据。当尝试解析数字时，不要简单地放弃；应该告诉用户您得到了什么数据，而且如果可能的话，还应该告诉用户该数据位于输入流中的哪一行上。
作为一个很好的例子，请考虑 dc 的两种实现之间的区别。如果您运行 dc /home ，其中一种实现会显示“Cannot use directory as input!”而另一种实现只是无声地返回，没有错误消息，也没有不寻常的退出代码。当您错误地键入一个 cd 命令时，您更希望当前路径中有哪一种实现呢？类似地，如果您提供某个目录中的数据流（或许是执行 dc < /home），前者会给出详细的错误消息。另一方面，当它在获得无效数据的早期就选择放弃可能是理想的。
安全漏洞经常植根于在意料之外的数据面前表现得不够健壮的程序中。务必记住，优秀的实用程序能够设法在 shell 脚本中作为根（root）用户身份运行。诸如 find 这样的程序中的缓冲区溢出可能会给大量的系统带来风险。
程序对意料之外的数据处理得越好，它就更可能适应变化的环境。通常，设法使程序更健壮会导致您更好地理解该程序的作用，从而更好地使之通用化。
新颖
要编写的最糟糕的实用程序种类之一就是您已经有了的实用程序。我编写过一个名为 count 的美妙的实用程序。它允许我执行几乎任何计数任务。它是一个出色的实用程序，但是已经有一个名为 jot 的标准 BSD 实用程序做同样的事情。同样地，我的一个用于将数据转换为列的灵活的程序重复了一个现有实用程序 rs 的功能，这个实用程序同样可以在 BSD 系统上找到，只不过 rs 更灵活，设计得更好。请参阅下面的 参考资料 以了解关于 jot 和 rs 的更多信息。
如果您即将开始编写一个实用程序，请花一点时间浏览一下各种系统，以确定那样的实用程序是否已经存在。不要害怕在 BSD 上借用 Linux 实用程序，或在 Linux 上借用 BSD 实用程序；实用程序代码的乐趣之一在于，几乎所有实用程序都具有很好的可移植性。
不要忘了考察一下组合现有应用程序来形成一个实用程序的可能性。从理论上讲，组合现有程序来形成的实用程序运行得不足够快是可能的，但是编写一个新的实用程序很少会比等待一个稍慢的管道更快。
文章整理：西部数码--专业提供域名注册、虚拟主机服务
http://www.west263.com
以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!
