今天突然疑问为什么 babel 的配置文件叫 .babelrc, 常见的还有 .bashrc...
转载文的第一行就回答了这个问题, 后面的内容没有仔细阅读, 好似也只是作者的笔记, 暂且先复制了一番,
转载: 配置文件后面的 rc 的由来
配置文件比较正规的叫法是：运行控制文件 run control
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(92个字符)文本控制台或虚拟终端窗口以字符为单位的列数，通过这个环境变量，CLI的程序可以了解一行内最多能输出多少字符
LINES文本控制台或虚拟终端窗口以字符为单位的行数，通过这个环境变量，CLI的程序可以了解屏幕上最多可以显示多少行文本
SHELL当前使用的shell的名字
PATHshell搜索可执行程序的目录列表
TERM(xterm)当前会话控制台或虚拟终端的名称。最大的用途就是程序能够知道可以使用哪些特性，比如是否可以输出中文等
需要注意的是，当程序是用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），多数不带参数
-gGDB调试信息，带或不带参数。主要用于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启用压缩，不带参数
