我最近搬到了鱼从巴什。我立即爱上了开箱即用的功能，但在配置 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/到目前为止，我想说单个文件更易于读取、维护和在主机之间移动。是否有一些建议遵循的约定？除了给予用户更多的自由之外，允许这么多级别的配置背后是否还有特定的动机？
答案1
就目的而言，我想说有几个充分的理由支持两者。
首先，也许也是最重要的，正如 @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; endconfig.fish