fish shell中使用者配置的多個位置（可能還有使用約定）的目的是什麼
我最近從bash開始**釣魚。我立即愛上了開箱即用的功能，但在配置 shell 時我有點不知所措。
啟動時，Fish 會評估許多配置文件…
- 目錄中以 .fish 結尾的文件中的配置片段：
+
$__fish_config_dir/conf.d（預設情況下，~/.config/fish/conf.d/） + …
- 使用者初始化，通常在
~/.config/fish/config.fish…到目前為止，這很清楚。來自 bash，我拿走了我的
.bash_globals和.bash_aliases文件，根據 fish 的語法稍微重寫了它們，將它們放入 中，~/.config/fish/conf.d/然後按預期載入它們。但是，當我查看
config.fish文件的內容時，我無法弄清楚需要放在那裡的任何內容。據我了解，fish 旨在開箱即用，因此HISTCONTROL不需要像設置這樣的常用 bash 配置。也不是conf.d/從某些主腳本呼叫的文件（如.bash_aliases等，將在 中.bashrc） - 它們是自動載入的。是否有一些特定的案例
config.fish比文件更受歡迎 - 甚至是必需的conf.d/？到目前為止，我會說單個文件更易於在主機之間讀取、維護和移動。是否有一些建議遵循的約定？除了給使用者更多自由之外，允許如此多級別的配置背後是否有特定的動機？
就目的而言，我想說有幾個很好的理由來支持兩者。
首先，可能也是最重要的，正如@Zanchey 在評論中指出的那樣，
conf.d支持是在 2.3.0 版本中出現的，所以在那個時候擺脫config.fish它將是一個突破性的變化。其次，正如您所說，使用者可以自由選擇他們想要處理啟動行為的方式。
其次，它也有點“阻力最小的路徑”。我絕對同意您對
conf.d/文件模組化的偏好，而且我喜歡沒有config.fish自己。但是一些（甚至大多數）fish第一次遷移到的使用者預設熟悉一個類似單一.bash_profile的地方來放置他們的配置。我可以想像，沒有單文件配置的範式轉變可能會讓一些人反感。換句話說，config.fish有助於為新使用者提供平穩遷移。此外，
config.fish更容易向新使用者解釋，因為它映射到他們在以前的 shell 中已經知道的東西。即使是fish常見問題解答也預設告訴使用者這config.fish相當於他們以前的啟動腳本。儘管我確實希望他們也能繼續在那裡解釋conf.d/替代方案。並且
config.fish確實還有另一個小優勢，即執行順序更加明確（即從頭到尾執行）。conf.d/文件的讀取與其他文件一樣conf.d/，按字母順序（或全域結果順序，很可能）。根據我的經驗，這意味著您必須使用00_dependency.fish命名類型來確保一個文件在其他文件之前執行。也就是說，很少有人不得不求助於它。至於“約定”，好吧，我知道許多發行版都
httpd.conf使用預設的“單文件”來設置它們的配置文件（例如 Apache2 ）來處理conf.d/結構。在fish這種情況下，他們只是取消for conffile in ~/.config/fish/conf.d/*.fish; source $conffile; end了config.fish.