Linux 設定檔策略

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 等的配置語言的文法很是類似的在設定檔裡面，所以不用擔心設定檔和語言綁定問題。