在学习Linux的时候，让人受不了的不单单是“规律无处寻”，还得去学习和掌握各式各样的配置文件。即便配置文件可以不用关心，环境变量也总是出来捣乱，让某些程序的行为“异常诡异”。即使这些你都想视而不见，只是想敲敲命令，鼓捣点你认为比较浅显的东西，各种命令的命令行选项也会绕得你头晕目眩。从此大叫一声：Linux咋就这么难学？ 这与前面刚说过的“规律无处寻”差不多，是导致初学者十分困惑的另外一个“笨”现象——配置乱生根。不过与“规律无处寻”所不同的是，后者还能有一个抓住本质的“机制”。要严格说起来，“配置”也算是一种机制。但是你要说“配置”是一种策略，也不见得不恰当。所以，“配置”跟其他某些具体的“机制”相比，就要显得飘渺了一些。 4.5.1 什么是不可配的 如果你要问Unix：“你有哪些东西能够配置？”Unix会非常无谓地答道：“一切！” 是的，就是一切。这源于“策略与机制相分离”的这种十分优良的传统：只要有可能，就建立机制并把策略的决定权交给用户。它所带来的最直接的收益就是，按照这种方式所开发出来的程序往往功能十分强大且非常灵活。但负面影响也不可谓不巨。虽然Unix真正的专家用户们用起来非常顺手，但是由于程序接口选项众多，配置文件像杂草一样随处生根疯长，也彻底打击了初学者和普通用户。 那么如果这个问题是问Linux的，Linux的回答就要比Unix谨慎很多：“需要的时候。”很多时候，这不能不说是Linux的一个进步。毕竟一味的追求传统就是教条主意的固步自封了。 其实Linux上的大多数程序都是源自于Unix的，所以很多时候你并不会发现这种改变的设计倾向。不过到目前为止，经过被称为“新学派Unix程序”的那些Linux开发者们的不断努力，已经有了很显著的变化。人们已经习惯，在设计一个程序时总是会考虑：哪些不应该可以配置！ 首先，对于能够可靠地进行自动检测的东西，就是不应该可以配置的。这是最容易犯的错误。比如在做并行运算开发的时候，经验告诉我们，并行数量至少应该与电脑的计算核心数量相匹配才好。好多程序员为了让这种程序具备普适性，提供了一个并行数量的配置，让使用者根据自己电脑的实际计算核心数量进行配置。但实际情况是很多用户从不去理会这个配置项，总是导致无法完全发挥程序的并行计算能力。而当你在文档中或口头培训中提及这个配置时，用户们的眼中浮现出来的永远是困惑。显然在程序中自动监测电脑有多少个计算核心要比提供一个配置项，对于用户来说要省事很多。而且检测电脑有多少个计算核心又不是什么困难的事情。 其次，用户不应该看到优化开关。让程序高效准确的运行永远是程序员的事情，跟用户没有半毛钱关系。最常见的一个反例就经常出现在一些视频格式的转化软件中。它们经常要求用户提供采用何种编码方案、多少码率等配置信息。其实用户要的就是转化成iPad，或者PS3能播放的格式。iPad只需要1024×768的分辨率就够了，至于PS3，很多人是想体验1080p全高清的震撼的。有多少用户能够知道iPad或PS3应该采用何种编码方案，多少码率才能体验全高清的震撼呢？ 最后，能用脚本胶合或简单管道实现的任务，就不需要配置。因为能够简单利用其他程序来完成的任务，就没有必要增加本程序的复杂度。一个比较正面的例子就是“ls”命令，它永远不会提供分页输出的命令选项。因为只需要结合“more”或“less”命令就能够提供这样的功能。 其实在Linux的这些“笨”中，只有“配置乱生根”是最为让人迷惑和诟病的特性。好处有、害处也不少。但并不能因为害处多就全盘予以否定，毕竟因它所能够带来的好处而获得的实际收益要比因害处所带来的实际损失要多很多。十全十美的东西是没有的，学习Linux的同学们，在这个地方就忍一忍吧-*_^-! 4.5.2 配置三元素 本节的最开始就说过的配置文件、环境变量、命令行选项，这些就是起配置作用的三元素。 由于Linux是一个多用户的操作系统，那么就必然会涉及针对不同用户的配置问题，必须要引出系统级别和用户级别配置的差别。所以如果要详细划分，可以划分为系统配置文件、系统环境变量、用户配置文件、用户环境变量和命令行选项。注意顺序问题，凡是跟系统有关的都是最高优先级、跟用户有关的都是低优先级，文件优先于变量，命令行选项优先级别最低。程序在查询配置信息时，都是要按照这种优先级排序来确认的。这样做的一个好处是，最后被确认的配置信息永远能够覆盖到最先确认的配置信息，最先确认的配置信息也可以帮助后面要确认的信息确定位置。由此可见，配置的响应优先级就完全是逆序的了。这与我们常规的理解是不矛盾的，毕竟通过命令行给定的配置信息，是用户最想获得的特性。 在考虑使用何种机制向程序提供配置信息时，要牢记这样的原则：调用时可能发生变化的配置信息，使用命令行选项；改动很少但确实应该由各个用户控制的配置信息，使用用户配置文件或用户环境变量；需要由系统管理员设置而不需要用户改变的整体系统级选项数据，应该使用系统配置文件或系统环境变量。 4.5.3 配置文件 配置文件比较文绉绉的称呼是“运行控制文件”，存放与具体程序相关的声明信息，有些时候甚至是可执行的命令，在程序启动时解析。 对于系统级配置文件，就像在第三章中描述的那样，应该放在/etc目录下。对于用户配置文件，应该放置在用户的“home”目录下，并且一般是隐藏文件。由于Linux下隐藏文件是以“.”开头的，所以这类配置文件也被称为“点文件”。 如果一个程序的配置信息很多，那么它也可以拥有一个配置目录或点目录。每个目录应该包含数个与同一个程序相关的配置文件。多个程序共用一个配置目录或点目录，很难保证不会出问题。 配置文件或配置目录的命名方式没有严格规定，基本上是保持与其所负责的程序的名称一致即可。一些较为古老的程序会使用一些较为古老的约定：使用可执行文件名后加“rc”后缀的方式（rc代表运行控制）。比如/etc/bashrc和.bashrc，前者是Bash的系统配置文件，后者是Bash的用户配置文件。更有的一些甚至就是以rc为名的，比如/etc/rc.d目录，大多数Linux发行版本都将它作为init程序的配置目录。 配置文件的内容同样没有严格规定，不过也有一些约定俗成的规则可供参考。比如在“万般皆文本”一节中提到的DSV风格的文本内容。如果配置的程序是某种语言的解释器，那么它的内容一般会使用具体语言本身。最为著名的例子就是shell本身和Emacs。前者的bashrc文件实际上就是shell脚本程序，后者的.emacs也是用Lisp编写的。当然，为了避免用户为了编写配置文件而不得不去过多地学习新的知识，最好的办法就是能够提供一个全方位的例子配置文件，并有相关文档说明，让用户能够容易地按照例子删减。优秀的云计算平台Hadoop就是一个非常好的例子。 4.5.4 环境变量 当Linux程序启动时，它的运行环境会包含一组名字和值的关联（名字和值都是字符串）。有些是由用户手工设置的，有些是由系统在登录时设置的，有些是由shell或虚拟终端 设置的。这就是环境变量。在Linux下，环境变量一般会携带文件搜索路径、系统默认值、当前用户ID和进程ID等信息，以及其他有关程序运行时环境的关键信息。 环境变量的读取是非常容易的。在C和C++中，环境变量的值可以通过库函数getenv获得。Perl和Python在启动时，会初始化环境变量字典对象。其他语言通常也都采用以上两种方式之一。常见的系统环境变量见表4-1的描述，注意大小写。 表4-1 常见系统环境变量 变量名 用 途 USER 当前会话登录的账户名（BSD约定） LOGNAME 当前会话登录的账户名（System V约定） HOME 当前会话的用户home目录，这个变量非常重要，很多程序要通过这个环境变量来了解自己的用户配置文件的位置 COLUMNS 文本控制台或虚拟终端窗口以字符为单位的列数，通过这个环境变量，CLI的程序可以了解一行内最多能输出多少字符 LINES 文本控制台或虚拟终端窗口以字符为单位的行数，通过这个环境变量，CLI的程序可以了解屏幕上最多可以显示多少行文本 SHELL 当前使用的shell的名字 PATH shell搜索可执行程序的目录列表 TERM 当前会话控制台或虚拟终端的名称。最大的用途就是程序能够知道可以使用哪些特性，比如是否可以输出中文等 需要注意的是，当程序是用shell以外的方式启动时，有些系统环境变量甚至是全部系统环境变量都还未设置。特别是那些守护进程，这些系统环境变量都还未设置——即使设置了，那些值也未必有意义。这类程序，尽量不要使用环境变量。另外，当环境变量有多个值的时候，需要使用冒号“:”作为分割，PATH变量就是最典型的例子。 其实环境变量有时候是很难区分什么是系统的，什么是用户的。如果一定要严格划分，那么任何用户都能访问到的就算是系统环境变量，但是值对于每个用户都可能不同，比如HOME。相反，如果只有某个具体的用户才能访问到的，就应该算是用户环境变量，毕竟那是因具体的某个用户而存在的。 尽管应用程序可以在系统定义的范围之外自由解释环境变量，但是这样的做法在Linux中是很少见的。而且环境变量也不适合把结构化信息作为值传递到程序中（虽然原则上可行）。所以，大多数情况都是直接使用现有的环境变量，标新立异的设计一个新的环境变量大多不是明智之举。应该优先考虑配置文件。 4.5.5 命令行选项 在Linux中，几乎所有程序都会提供几个命令行选项。这样做的一个好处是程序的配置信息可以由脚本指定，这对于作为管道或过滤器的程序尤其重要。 有三种约定可以区分命令行选项和普通的参数：原始的Unix风格、GNU风格和X tookit风格。 原始的Unix风格命令行选项，是以连字符“-”开头的单个字符。如果选项后面不带参数，则被称之为模式选项，模式选项是可以组合在一起使用的。例如，如果-a和-b是模式选项，那么-ab或-ba就都正确，而且会启用这两个选项。如果选项有参数，这些参数要紧接在选项后面（是否以空格分隔可选）。 GNU风格则使用两个连续的连字符“--”后接选项关键字（注意，不是单个字符）。这种风格是因为有好多程序过于复杂，导致单个字符不够用了而发展起来的一种治标不治本的方法。较原始的Unix风格更容易让人理解，但作为我们这种非英语为母语的同胞们也经常输入错误或记不住。GNU风格的选项不用空格分隔就不能组合使用。选项参数既可以用空格分隔也可以使用单个等号“=”来分隔。 最让人痛恨的恐怕应该是X toolkit风格了。它使用单连字符和选项关键字，并且由X toolkit进行解析。最要命的是，X toolkit先要过滤并处理某些特别的选项，比如-geometry和-display，然后再把过滤好的命令行传递给应用程序去解析。如果你不清楚它会过滤哪些选项，就会死活都找不出你的程序为什么接收不到某些选项。所以，这种东西最好别碰它。 在表4-2中我列举了最常用的Unix风格命令行选项的含义，从a到z都覆盖到了。如果你的程序需要提供某些方面的配置选项，那么可以直接使用。如果遇到冲突了，那么最好采用GNU风格。因为这样，可以使你的程序非常通用，也容易理解。当然，这对初学者也是有帮助的，因为Linux下大多数程序也是按照表中的约定去做的。 表4-2 常用的Unix风格命令行选项的含义 变量名 用 途 -a 所有选项（all），不带参数；或添加（append），这个时候与-d相对应 -b 缓冲区（buffer）或数据块（block）大小，带参数； 批处理（batch），不带参数 -c 命令（command），带参数；检查（check），不带参数 （续） 变量名 用 途 -d 调试（debug），带或不带参数；带参数指定调试信息级别，这个非常普遍； 偶尔具有删除（delete）或目录（directory）的含义 -D 定义（define），带参数。比如C编译器的宏定义； -e 执行（execute），带参数；编辑（edit），不带参数； 偶尔具有排除（exclude）或扩展（extend）的含义 -f 文件（file），带参数，表示文件输入；强制（force），多数不带参数 -g GDB调试信息，带或不带参数。主要用于GCC来生成GDB的特有调试信息 -h 表头（header），通常不带参数。启用、禁用或修改程序生成报表的表头； 帮助（help），或许这是最普遍的理解 -i 初始化（initiallize）或交互（interactive），通常不带参数 -I 包含（include），带参数，比如C编译器的头文件搜索路径 -k 保留（keep），不带参数，禁止某个文件、信息或资源的常规删除操作； 偶尔有杀死（kill）的含义 -l 列表（list）、长模式（long）或登录（login），不带参数； 加载（load），带参数；偶尔会有代表长度（length）或锁定（lock）的含义 -m 消息（message），带参数； 偶尔具有邮件（mail）、模式（mode）和修改（modify）的含义 -n 数字（number），带参数；否（not），不带参数 -o 输出（output），带参数 -p 端口（port），带参数；协议（protocol），带参数 -q 安静（quite），不带参数。禁止正常的结果输出或诊断输出 -r或-R 递归（recurse）或反向（reverse），不带参数 -s 缄默（silent）,不带参数。与-q类似，如果两者都支持，-q表示“安静”，-s表示“绝对缄默”；主题（subject），带参数；偶尔具有大小（size）的含义 -t 标记（tag），带参数 -u 用户（user），带参数 -v 冗长（verbose），带或不带参数；版本（version），不带参数 -V 版本（version），不带参数，比-v常见 -w 宽度（width），带参数；警告（warning），不带参数 -x 启用调试，同-d类似，带或不带参数；提取（extract），带参数 -y 是（yes），不带参数 -z 启用压缩，不带参数