我最近搬到了鱼从巴什。我立即爱上了开箱即用的功能,但在配置 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; end
config.fish