点文件和点配置有什么区别?

点文件和点配置有什么区别?

例子:

  • .bashrc
  • .config/fish/config.fish

我想知道哪种更常见以及它们各自有什么优点和缺点。我想点文件会更容易更改,因为它位于主目录中,但它似乎.config更容易携带,因为它是一个包含所有内容的目录。

应用程序通常只支持其中之一,还是两者都支持?

选择一个然后为每个应用程序建立符号链接是个好主意吗?例如,如果我想要一个点文件,我可以使用ln .config/fish/config.fish .fish并编辑.fish,对吧?

答案1

点文件是较旧的形式,我相信完全避免它们是很困难的,除非您使用的发行版坚持修补包含的每个软件以使用.config目录树而不是普通的点文件。许多旧的应用程序都有使用特定点文件的悠久历史;有些可能有自己的点目录。其他人实际上可能两者都有:例如,vim支持.vimrc,但也.vim/有多个文件和特定子目录结构的目录。

目录.config结构基于XDG 基础目录规范。它最初被 GNOME 和 KDE 等桌面环境所采用,因为它们最初都有大量的每用户配置文件,并且都已经独立选择了有些相似的子目录解决方案。

对于 GUI 文件管理器来说,隐藏文件的概念可能会有问题:如果您选择默认不显示以点开头的文件和目录名称(遵循经典的 unix 风格行为),GUI 用户将无法轻易发现点文件的存在和功能。如果您选择不隐藏点文件和目录,您的主目录中就会出现很多混乱,从某种意义上说,主目录是您个人工作区的绝对顶层。这两种方式都会让某些人不高兴。

将每用户配置文件推送到专用子目录可能是一种有吸引力的解决方案,因为只有一个子目录而不是多个点文件和/或点目录将减少在 GUI 中显示“隐藏”文件时的混乱情况,并且访问便利性差异也不是太大。但它违背了用户长期以来的期望:(一些)点文件“有总是来过这里并命名为”。

这将是一个非常基于意见的问题。

如果点文件与登录访问或某些其他特权访问控制无关,您可以使用符号链接从一种约定桥接到另一种约定,无论您喜欢哪种方式。但是,如果您确实经常编辑特定的配置文件,以至于易于访问很重要,也许您可​​能想要创建一个 shell 别名或桌面图标/菜单项,以便立即在您喜欢的编辑器中打开实际的配置文件(使用绝对路径名)反而?它可能是更方便

一些点文件和目录由特权进程访问(例如作为身份验证和访问控制的一部分),例如~/.ssh~/.login_conf例如等,并且它们通常不能被符号链接替换,因为这些进程需要实际文件而不是指定位置的符号链接,以禁止各种欺骗和利用。如果要重新定位这些文件,必须通过修改相应进程的配置来完成,通常是系统范围的配置。

相关内容