Comment by Hendrikto
1 day ago
If people just followed the XDG Base Directory Specification, config file littering would be a non-issue. More and more projects adopt it, even holdouts like Firefox.
1 day ago
If people just followed the XDG Base Directory Specification, config file littering would be a non-issue. More and more projects adopt it, even holdouts like Firefox.
I wonder how many apps actually read the correct XDG environment variables and obey them, versus just hardcoding paths that match their machine’s config paths (typically ~/.config/*)
I almost want to set up a VM that sets up XDG_CONFIG_HOME as ~/.foobar and see how many apps actually respect it, and how many still write to ~/.config.
A few years ago I had a Windows box where I pointed XDG_CONFIG_HOME et al to the corresponding-ish Windows paths (AppData subdirectories, mostly) so that the many Linux-derived CLI programs I was using wouldn't clutter up my userdir, and it worked pretty well, though there were a few programs that didn't get the memo. Unfortunately I don't remember which ones they were. Most programs get it right, though!
I don't see much difference between a program littering in ~/.app versus littering in ~/.config/app, ~/.local/share/app , ~/.local/state/app and ~/.cache/app
The difference is big. I want my home directory to be clean, whereas .config is meant to be littered.
I don't have strong feelings one way or the other, the files are hidden so out of sight out of mind for me.
I don't disagree that it would be cleaner if things were more organized, but I definitely prefer something more like that the person you replied to said, ie "~/.xdg/foo/{config,share,state,cache}"
The only XDG folders that seem reasonable to me are .local/share/fonts and .local/share/applications, and I think both of those are still just conventions, not actually described in any spec.
I don’t mind ~/.* for config, especially when the config is just one or two files. What I don’t like is programs like go and cargo treating my $HOME as a dumping ground for every file they want to download and/or cache.
At least cargo places everything in a .cargo directory, so it doesn’t display by default. Go will instead write to $HOME/go, without even the decency to use a hidden directory, unless you first define the GOPATH environment variable.
And if you install more than one version of go, they get placed in $HOME/sdk [0]. Last I checked, this path is hard-coded with no override, despite this being a known issue for 8 years.
[0] https://github.com/golang/go/issues/26520
In general, I find it unacceptable for programs to use (anywhere in) my file system, besides /tmp, as a dumping ground for their caches and downloads, without cleaning it up.
> In general, I find it unacceptable for programs to use (anywhere in) my file system, besides /tmp, as a dumping ground for their caches and downloads, without cleaning it up.
/tmp must be world-writable and for multi-user or multi-tenant systems it becomes a security hole. Storing temporary files in the current user's home directory (or a subdirectory thereof) makes sense.
What doesn't make sense is this blog post about TMP and TEMP, and ending with "I don't know why" (in different words).
The reason is simple: different programmers thought the other name was bad. They were under no obligation to come to a consensus.
Don't forget about TEMPDIR and TMPDIR! Also Windows has its own environment variables for this. But generally, Linux software ported to Windows still use TMP or TEMP.
1 reply →
I contemplated for years and eventually saw someone implement a transparent kernel redirect for programs reaching for ~/.*