第3章 The Bourne-Again Shell
Bash的主要组件：输入处理，解析，单词展开(word expansion)和其他命令处理，管道(pipeline)中的命令执行。这些组件构成一个流水线(pipeline)，从键盘或脚本中获取字符，然后逐步转化为命令。
图3.1 Bash组件结构
3.7. 经验教训
3.7.1. 什么是重要的
参与到Bash项目中已经有20多年，在这期间我也获益良多。最重要的一点是一定要保留详细的修改日志，其重要性怎么强调都不过份。通过阅读修改日志来回忆起当初的想法，感觉是很好的。甚至你还可以将某个修改与一个bug报告联系起来，然后编写一个重现bug的测试用例或提出一些建议。
如果条件允许，我建议在项目之初就考虑全面的回归测试。Bash拥有数千个测试用例，覆盖了差不多所有的非交互性功能。我考虑过测试交互式功能，其实Posix标准的一致性测试套件中就有交互性测试，只是并没有将这个测试框架发布出来(我认为很有必要)。
标准很重要，Bash受益于它是一个标准的实现。参与到你正在实现的软件的标准化过程中来也是非常重要的。在讨论相关功能和行为时，标准往往是最终的参考依据。当然，前提是这是一个好的标准。
外部标准重要，内部标准同样重要。我很幸运地接触到了GNU项目的诸多标准，它们包含了大量关于设计和实现方面的好且实用的建议。
好的文档同样非常关键。如果你希望别人使用你的软件，全面并清晰的文档就是必要的。一个成功的软件必须拥有大量的文档，因而开发者提供权威的版本就显得非常重要。
优秀的软件随处可见，那就充分利用起来吧。比如，gnulib中包含了大量的有用的函数，你尽可以把它们"抠"出来。BSD各个版本和Mac OS X就是这么干的。Picasso说过：好的艺术家靠的是偷，说的就是这个道理。
参与用户社区，但是准备挨骂，有时候这并不好受。活跃的用户社区好处是显然的，但是这些人可能会非常情绪化，不要太当真就好。
3.7.2. 如果可以重来
Bash拥有数百万用户，我知道后向兼容有多么地重要。在某种意义上，后向兼容意味着永远不用向用户说抱歉。但是，这个世界远不是这么简单。事实上，我不得不一直做一些破坏兼容性的修改，比如修正一个不好的决定，修改一个错误的设计，或者更正shell不同部分之间的不兼容性，这些都是情有可原的修改，但是几乎都会引起一些用户的抱怨。我早就应该对当兼容性分级处理的。
Bash的发展一直都没有特别的开放，我已经习惯于里程碑发布形式(比如 bash-4.2)并由个人提交补丁。我的理由是：我需要适应开发商们更长的发布周期(相对于自由软件和开源世界)，而且我也有过beta版本传播地过于广泛的不快回忆。当然，如果一切都要重来，我还是会考虑更快的发布频率，比如可以使用一个公开的源码仓库。
不真正动手去做是完不成任何事的。有一件事我已经考虑了很久，却一直没去做，那就是将Bash的解析器重写为递归下降(recursive-descent)的方式，以取代bison。以前，我以为为了遵守Posix标准，这件事就非得做，但是后来我只需要少量修改就解决了这个问题。如果当时就从头写起，大概现在我已经实现了一个新的解析器，那么很多问题都会变得简单得多。
摘自：http://www.ituring.com.cn/article/6220