Taking this opportunity to remind folks: if you're going to emit a config file from your program, check for $XDG_CONFIG_HOME and use what you find by preference. ~/.config is a decent fallback. Sticking it in ~? It's not the 1980s anymore, please, don't.
Config files are the lesser problem, although it's really, really, really useful for programs to realize that $XDG_CONFIG_HOME exists.
More importantly, please put your caches under $XDG_CACHE_HOME so they don't trash up my backups or git.
And if you're feeling really fancy, put all your runtime stuff in a separate dir in $XDG_RUNTIME_DIR so /tmp doesn't look like someone detonated a zip bomb in there. I want to use it for my temporary files and still find them, thank you very much.
So it's OK to hide the mess, by throwing everything from the living room into the closet, I guess?
Not to mention, in the old days, that stuff was modtly in dot files.
(Users install graphical file manager. User has file manager set to bizarrely show dotfiles by default. User gets mad at prior hidden "clutter". Now dotfiles hidden one dir down.)
> So it's OK to hide the mess, by throwing everything from the living room into the closet, I guess?
Yes? This is literally how every human in the world does it. You put your things, according to catrgories, into their respective room/cabinet. If somebody asks you where your sweaters are, you don't say "just search the ground", you say " in the closet".
Same thing here. You don't have to guess where files are, you know by convention.
I don't think it's all that weird, it's one of the first things I'd do in any file manager and I make sure Windows Explorer shows me system files too. If never had to interact with the hidden config it would be one thing, but I very often do and I don't want extra friction in getting to them.
~/.programname is an unorganized mess, where someone stuff their dirty laundry, their trash, their food and their passport into the same closet. It doesn't matter if the closet is open or not, nobody but the mentally ill hoarder who created the mess can navigate it.
~/.(local|share|cache) means people put their food in the fridge, their trash into the bin and their sensitive documents in a fire proof safe. Which means other people can take care of basic tasks like taking out the trash and creating backups of their sensitive documents.
~/.(local|share|whatever) means I have to search both the basement, the attic and the garage. For stuff i rarely need to touch so I forget every time where it was placed.
If it was only one place it would be great. If it was truly separated by config vs cache it would be great. The reality know though is that you have at least three locations where important config are stored, not counting those from package managers that have their own idea of this concept. Still, this mess is preferable to the even worse mess of hundred plumbing files spread on the living room floor.
The one thing I despise about local|share|config is I never know which one they're using or what kind of nested hierarchy they're using that means I might have to search for the company name first.
At least with the ~/.whatever system I can just start typing ~/.tool-name, hit tab and it'll show me the thing if it exists. If it's somewhere else I have to look it up.
> The one thing I despise about local|share|config is I never know which one they're using or what kind of nested hierarchy they're using that means I might have to search for the company name first.
This really only applies to badly ported Windows software like Unity engine games. There should be no hierarchy, just ~/.{local/share,config,etc.}/$application
And nothing stops badly behaved software from deciding to use ~/.$CompanyName or heck I have even seen ~/My\ Documents/$CompanyName
I have a real filing cabinet. In it, I have folders.
I don't keep my backup car dongle in one folder, my car invoice in another, my warranty and info from dealer all in different folders. They're all in a folder with the car name on it.
The same for my fridge. The invoice, the manual, the warranty info, all in one folder.
It is much more disorganized to have a folder for manuals and put them all there. I have to find the one I want out of 50 such manuals. And if it is a warranty thing, then I need the invoice, and other papers.
Why would I want to keep associated things in different folders?!
You think it's a mess, but really it's not. It's organized for humans to find related things.
Before, I'd uninstall a program and delete its single dotdir. Done.
Now I have to hunt in a maze of madness to "get it all".
You cite some programs that didn't properly keep their data in a single dotdir, and use that as a reason why a single dotdir was bad?!
> You cite some programs that didn't properly keep their data in a single dotdir, and use that as a reason why a single dotdir was bad?!
No. It's literally the other way around. It's bad that they keep everything in a single dotdir, because now I have to poke through dozens of folders to see where they hide their caches and other bloated garbage that shouldn't be backed up or kept in git, and where between all that garbage they're hiding their config files.
If all caches go to ~/.cache, I can exclude them all with a single setting, and I can put all my configurations in git/backups by adding ~/.config.
Same as with /var/tmp vs /etc vs /var/lib; if I want everything thrown together into a single folder I can just go use Windows.
> people still can't get used to .local/.share/.config
I'm one of those people... I don't want yet more hidden stuff in my home dir; I want less. My dream is to have zero hidden directories in my home. What I want is something really clean like this:
$ ls -a ~
. .. config fun local pro tmp
This is almost possible, thanks to XDG_ environment variables. But unfortunately many programs still use hardcoded names for the local userdirs.
If you want to get closer to that goal, the xdg-ninja [0] package can help you. Also, do something like "touch ~/.local ; chmod 000 ~/.local" to force programs that use hardcoded names to fail spectacularly (instead of recreating the hidden dir).
