> this could invalidate the information contained in that in the man file.

No, it doesn't. The point of modetc is precisely keep both myself and the programs happy: the files are actually stored where I like to keep them, but they can be accessed as if they were stored where the developer intended.

You're not wrong. In a worst case scenario I resort to using strace to figure out where a program is reading config from.. from what I understand, if this kernel module is in use then even that approach wouldn't help.

But since the use case is personal dotfiles, I imagine the user isn't going to forget that they set this up.

> working out where configuration information is

Generally, good behaved applications have an entry in their man page that spells out these details for you, so you don't have to work out anything.

To be fair the author shows an example of using NixOS. It's absolutely another layer of indirection (probably several) but it does make that usual Linux "fun" less problematic because of its immutable nature and API design.

Tomorrow: modify man pages from kernel space!

Always check the man pages..

Well, it's just the natural extension of the FHS convention to the home directory.

I didn't come up with this idea, though, I think I saw this in a reddit thread and started doing it myself: I like that the directories are visible and follow the usual structure.

Hi, author here: whether it's a valid use case depends on your level of OCD, but the difference compared to symlinks or bind mounts is that you will have a clean home: e.g. `ls -la` won't show any "hidden" files.

Also, completely unrelated to my motivation, someone pointed out that modetc could be used to quickly hotfix packages built with Nix. Say that you need to fix a CVE in openssl, normally that would require to rebuild all dependent packages, which takes a long time. Instead with something like modetc you could build just openssl and rewrite /nix/store/<hash>-openssl-3.6.0/ -> /nix/store/<hash>-openssl-3.6.0-hotfix/.

Another application might be replacing some configuration file with placeholders for secrets, with one file with the secrets substituted in, without having to modify it in place, possibly only for a specific UID. This is something you might find useful on NixOS.

If I symlink ~/.ssh -> ~/.config/ssh, I still have .ssh in my ~. Whereas if I rewrite it, I don't.

The use case is that you can actually use your home directory without either (a) hiding files or (b) wading through 40 config files and dirs that XDG ignorant devs put there.