I have been doing this for decades. My files are in a sub-directory of $HOME. It also makes it very obvious when a piece of software does not treat your $HOME with respect.
On Windows this was always easier because, for some reason, most everyone respected %appdata% compared to XDG_CONFIG_HOME, but also because hidden files wasn’t just a naming convention but an actual separate metadata flag.
Always... Except for the decades before this became common. Never a bloated C: root directory. Microsoft even had games store stuff in My Documents\Games at one point. My Documents was a user dir that saw a lot of abuse over the years.
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.
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.
One of the annoyances of Linux is working out where configuration information is, following through multiple layers of indirection and files over-riding other files. This looks like adding another layer, another place to look, and if you're reading the man file for a shell (for example) it probably won't even mention that this could invalidate the information contained in that in the man file.
And I said that the man pages would be a part of what you have to examine. 95 pages in the case of bash (that's after running it through troff). man pages were fine when they were three pages long, but their lack of any internal index has become a problem.
Ok, now you might have a dozen files which could contain the information, where the location of each file can be modified by environment variables. It's tolerable if you are working on something you change weekly, but a practical problem if you do it yearly or it's entirely new.
'man bash'. Type G. Press PgUp until you see the FILES heading (took one press for my terminal size). There's your list of files. Alternatively, instead of G and PgUp, type /FILES<Enter>.
Of course, this doesn't help at all when software either doesn't have manpages, or doesn't include the list of files in the manpage. Just nitpicking your bash example.
This is HN, not Reddit. You can safely assume that every single person here knows how to use man, particularly if they mention using troff to format it properly. There remains a problem.
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.
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.
> 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.
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.
Why not push it under a hidden directory? Like ~/.local/etc? If we're reconstructing some of the hierarchy I think it makes sense to group and hide. Isn't the problem that the home folder is getting cluttered?
Why would I hide them? They're not really special and since I'm organising them with modetc they're not cluttered.
For reference, my home looks something like this
~
├── bin binaries and scripts
├── etc configuration files
├── var
│ ├── lib program data
│ └── cache program caches
├── src git repositories
├── img pictures
├── mail email in maildir format
├── note text notes, todo
├── doc documents
└── down downloads
yokoprime | 13 hours ago
regularfry | 13 hours ago
hvenev | 13 hours ago
txtsd | 13 hours ago
jl6 | 12 hours ago
I just treat ~ as a system-owned configuration area, and put my actual files (documents, photos, etc.) in a completely different hierarchy under /.
oftenwrong | 9 hours ago
SAI_Peregrinus | 5 hours ago
trollbridge | 10 hours ago
ComputerGuru | 7 hours ago
Sardtok | 6 hours ago
SAI_Peregrinus | 5 hours ago
Joker_vD | 7 hours ago
user3939382 | 11 hours ago
rnhmjoj | 9 hours ago
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.
tengwar2 | 13 hours ago
deafpolygon | 12 hours ago
tengwar2 | 6 hours ago
Ok, now you might have a dozen files which could contain the information, where the location of each file can be modified by environment variables. It's tolerable if you are working on something you change weekly, but a practical problem if you do it yearly or it's entirely new.
BenjiWiebe | 4 hours ago
Of course, this doesn't help at all when software either doesn't have manpages, or doesn't include the list of files in the manpage. Just nitpicking your bash example.
tengwar2 | 3 hours ago
skobes | 12 hours ago
mariusor | 11 hours ago
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.
user3939382 | 11 hours ago
mariusor | 11 hours ago
ktm5j | 10 hours ago
But since the use case is personal dotfiles, I imagine the user isn't going to forget that they set this up.
brianjlogan | 9 hours ago
rnhmjoj | 6 hours ago
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.
user3939382 | 11 hours ago
pimlottc | 10 hours ago
amusingimpala75 | 7 hours ago
rnhmjoj | 7 hours ago
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.
godelski | 6 hours ago
rnhmjoj | 6 hours ago
dividedbyzero | 6 hours ago
rustyminnow | 5 hours ago
simonkagedal | 7 hours ago
Joker_vD | 7 hours ago
ycombinatrix | an hour ago