在 Fish shell 中进行用户配置的多个位置的目的(以及可能的使用约定)是什么?

在 Fish shell 中进行用户配置的多个位置的目的(以及可能的使用约定)是什么?

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

相关内容