1. Souce 解析 config 文件
尝试到Linux 的设计的好处，直接可以把config 文件当作脚本来执行。
configure 文件，一般都是一些键值对，对于强类型语言C /C#，一个简单的配置文件，需要程序去解释，去读。 但是再shell 里面，这些变的太简单，配置文件，也就是代码。
举例：
## Where deploy output is stored
LOG_DIR=log
## The directory to perform the Perforce sync
P4_ROOT=~/p4/current
代码里面直接把这个文件导入执行就可以：
source test.config
echo ${P4_ROOT}
简而言之，配置就是代码。 不知道是设计的时候已经考虑，还是恰好就这样，总之，生产效率这样就上去：）
2. 一个好的策略对于配置文件，就是分开全局的文件和局部的文件，局部文件覆盖全局文件。
这个策略很是方便，将不太容易改变的东西放入全局配置文件，可能多个用户可以共享。 对应每一个用户自己的特殊设置，放到自己本地，局部 local 的配置里面。
程序里面很简单只要用本地的配置覆盖全局的配置就可以。
更进一步，对于经常变动的，可以加命令行参数。 命令行参数 -----》 本地配置 -----》 全局配置。这样用户更方便。
如果可能，提供一个接口，让用户把某一次的命令行参数直接去覆盖本地配置文件。
貌似，Linux 上面的好多软件都采用这样的策略，比如vim ，她的配置文件再 /etc/vim 和 ～/.vim 下。
反过来想想：
如果将所有的都放到命令行，使用者将崩溃，每次累死累活的去输入那么多？ 而且还会出错。
想到看的书"The Art of Unix Programming "，对于配置文件有这么一章:
讨论这个问题 “配置文件放在哪里”？
1. /etc 下的运行控制文件（或者系统中固有位置）
2. 有系统设置的环境变量。
3. 用户主目录下的运行控制文件。
4. 用户设置的环境变量
5. 启动程序的命令行开关和参数。
还有一条对于配置文件的说法：
如果程序是某种语言的解释器, 那么人们就期望运行控制文件只是以该语言语法写成的并在启动时执行的命令文件。
所以配置文件是针对某种解释语言的，就用该语言的语法写，在运行的时候加载。就如上面的例子shell 对应的配置语言，用shell 的语法写，用source 加载; python 用 from xxxconfig import *。
python,perl 等的配置语言的语法很是类似的在配置文件里面，所以不用担心配置文件和语言绑定问题。