本人第一次发帖，多多包涵。 
前提提要：鄙人是一个不完全的极简主义爱好者，还有点强迫症。除了每天纠结于代码命名，最令我头疼的就是这个杂乱的 $HOME 目录。尽管考虑到 GNU/Linux 的自由性和一些历史原因，这种情况无可厚非。当然也会有人说，眼不见为净/事物的发展不随人的意识转移/…… 当然有时过于规范也会令人头疼，例如 Windows 软件总想在我的C盘里拉
。
当然，话说回来，和我有同样想法的人肯定也不想每次在 $HOME 输入 ls -la 时看到那么一托点文件吧，特别对于我重度终端用户，而且这会让我管理点文件很麻烦，总感觉不够一致。不过所幸在 Linux 也有了那么一个规范，即 XDG Base Directory Specification 。而且现在几乎所有比较新的软件安装都默认遵循这个 XDG 规范。甚至一些比较大型的软件，例如 firefox 最近也支持了这个规范。这是一个好兆头。
当然，还存在一些软件并不支持该协议。据我所知有以下几个原因：
- 开发者不完全了解Linux，并不知道该协议。这在一些跨平台软件比较常见。
- 开发者不愿或不屑于为此去修改，并且可能在早期开发时硬编码路径而难以适配。 这在一些大型软件，尤其是商业闭源软件尤为突出, 因为没有任何收益。
- 出于安全或顾及下游。这可能是一些Linux核心软件，例如 ssh，bash。像路径更改会触发连锁破坏反应，几乎不会适配。
- 诞生于 XDG Base Directory Specification 发布之前，在设计之初当然就不可能遵循， 对该协议的支持的态度可能与上述提到的1, 2, 3 相似。
- ……
目前我所知的一些软件保持 XDG-compat 的方法:
- 通过搜索路径支持：例如
vim，emacs,git,conda等。兼容性最好，不会破坏原先的配置，并且可手动 mv 至对应的XDG目录。 - 支持通过环境变量修改：例如
less，gnupg等。灵活性最好，你甚至可以指定任意路径， 当然最好还是使用规范的XDG路径。 - 通过命令行参数读取：例如
yarn,svn等。这通常仅适用于指定配置文件的路径，可通过别名的方法持久化。
那么，对于那些未提供任何方式来保持 XDG-compat 的软件，一个比较取巧的方式是使用沙盒版本，例如安装其flatpak版本。尽管这并不遵循 XDG 规范，但从某种意义上达到了其效果 (仅多了个 .var/ 目录)。
不同的软件的迁移方式有所不同，而且修复程度也有所不同。主要就是围绕我提到的那几个方法来解决，我主要是通过Arch Linux wiki: XDG Base Directory#Hardcoded 记录的方法来进行的，也有一些相关的工具能辅助你完成这项工作：
- xdg-ninja: https://github.com/b3nj5m1n/xdg-ninja
- boxxy: https://github.com/queer/boxxy
- antidot: https://github.com/doron-cohen/antidot
当然，这只能尽可能减少，一些软件到目前为止依旧没有解决方案。不过就算这样我已经很满足了，附上一张我目前的 $HOME 目录
这是我的与之相关的 shell 文件，感兴趣的可以参考一下：
不过最后我要提醒一下，任何的迁移都存在一定风险。一般情况下我不建议在你常用的用户家目录进行迁移，因为考虑到使用习惯和可能存在的硬编码路径问题，除非你了解迁移过程。对于新用户，考虑到大部分软件默认都遵循 XDG 规范，因此需要的迁移工作量就不是很多。
