The XDG base directory specification[0] was initially introduced in 2003; 20 years ago now. Yes there's plenty of software that existed before 2003 which didn't respect XDG, but most all of the Linux software dumping dotfiles in my homedir where written not just after 2003, but many years after 2003. For example, the following pieces of software all have dumped garbage in my homedir, and all are much less than 20 years (or even 15 years) old:
There's no excuses for these programs not respecting standards that are 1. Well established by the time the software was written and 2. short (seriously, the standard's contents fit entirely on three A4 pieces of paper)
> There's no excuses for these programs not respecting standards that are 1. Well established by the time the software was written and 2. short
This isn't a standard, it's a convention at best. A freedesktop.org specification. Basically a scheme Red Hat people thought up and implemented widely in the open source software projects they control. It may be a useful abstraction but there's absolutely no obligation to conform to it. There doesn't have to be an "excuse" or any form of justification at all. "I just don't like it" is enough. I don't like those unsightly XDG variables either and it's entirely within my power as a software developer to trash the entire concept of XDG and do things in any way I see fit.
This is the world of Unix, there's very little obligation to do anything other than convention. That's technically true, just like you can write your software to ignore all signals, or write your software such that it assumes it's always run as root for your convenience. That may be more convenient for you the developer, it's true.
But those are all generally poor ways to write software, and a great way to get your users to complain. So it is with ignoring XDG.
To put configs in ~/.program is the convention I learned, not ~/.config/. That came later, and I see 0 reason to pick it up. It's an annoying new hierarchy which I don't even like as a user, so I certainly wouldn't follow it as a developer.
If the programs in question implement the XDG base directory spec properly, then putting `export XDG_CONFIG_HOME=$HOME/.program` in your .profile will make them put config files in .program, not .config.
Sure, XDG was introduced in 2003, but why would you expect developers to start to follow its rules instantly? At best, it started to gain some traction 4 or 5 years after that, but still today, it is far from universally accepted.
But take a step further back: why should anyone care about what the XDG says in first place? This isn't a dictatorship, and things were doing just fine long before a handful of people who wrote the XDG thought their ideas were the best approach.
It's been my observation that good standards can be adopted broadly and quickly with little controversy or need for advocacy. The fact that the XDG file layout still isn't universally used suggests it doesn't have as much value as its proponents think.
> But take a step further back: why should anyone care about what the XDG says in first place?
Because their users are asking them to not pollute the home directory? This isn't bikeshedding config locations without reason, there is a clear motivation for letting users a) specify where data should go and b) separate different types of data.
> It's been my observation that good standards can be adopted broadly and quickly with little controversy or need for advocacy.
The XDG basedir spec has been adopted broadly amongs many organizations and individual devlopers including all major desktop environments. It is not adopted universally yet, but few things are.
But why should developers conform to that specific standard, if (for them, and many of their users) it makes more sense to use a "~/.wine" (or whatever other) folder?
If i want to completely remove wine from my profile, how many folders do I have to delete doing it the old way? One - ~/.wine. How many using the new? One in .config, then .local/share, probably one in .cache... oh wait, .local/state too.. Probably.. well, maybe, I'd have to check manually. Same for other software. One folder to remove, one folder to backup, one folder to restore.
Following the standard does not require you don't have a single folder, it can all be changed with 4 simple environment variables. If you want to have everything dumped horrendously in your home folder nothing is saying you can't, it just wouldn't be the default, because it's simply not an orderly way to organize the files.
The biggest problem is programs that don't even let you change where they store the stuff, so even if you're okay with the default not being XDG you dont even have the option to make it respect XDG base directory specification.
Whenever I install directly instead of using e.g. apt (typically because I want a more current version than the distro has), I use GNU stow [0], for precisely this reason. It works at the system level, at the user level, within projects, wherever. A simple "stow -D" is all it takes to clean out all the directories.
There is a single base directory relative to which user-specific data files should be written. This directory is defined by the environment variable $XDG_DATA_HOME.
There is a single base directory relative to which user-specific configuration files should be written. This directory is defined by the environment variable $XDG_CONFIG_HOME.
Neither of those environment variables is defined on a stock Ubuntu 22.04.1 LTS.
$XDG_DATA_HOME defines the base directory relative to which user-specific data files should be stored. If $XDG_DATA_HOME is either not set or empty, a default equal to $HOME/.local/share should be used.
$XDG_CONFIG_HOME defines the base directory relative to which user-specific configuration files should be stored. If $XDG_CONFIG_HOME is either not set or empty, a default equal to $HOME/.config should be used.
$XDG_STATE_HOME defines the base directory relative to which user-specific state files should be stored. If $XDG_STATE_HOME is either not set or empty, a default equal to $HOME/.local/state should be used.
I like this system overall, but this particular aspect seems like a mistake [0] to me. Instead of a simple rule like "use these envars", it has this more complicated logic that must be replicated in all apps supported by all developers. Users would have more agency if they could inform apps of their preferences by simply setting some envars. [1] If this simpler, more user-friendly regime had been in the spec, we would have seen better adoption initially and also two decades later.
[0] of course one shouldn't assume that a totalitarian decision is a mistake, because it's just as likely that the decision-maker has priorities other than "support users"
[1] yes of course users have agency with respect to where XDG is implemented, but the simpler rule would also have given them agency with respect to whether it is implemented
And the variables should not be set if the user/distro wants the default (probably to force developers to handle the default case which is needed for compatibility anyway).
Right now I have in my home folder 4 undesirable dot something which should be somewhere else and I can't change it. Meanwhile, I have 63 folders in my .config which means most of the applications I'm using do respect the XDG base directory specification, only a few entitled or extremely legacy ones don't.
.SpaceVim.d - My fault, I should write my own vimrc but I'm lazy
.steam and .steampath and .steampid - Steam
.vscode-oss - VS Codium
.w3m - w3m cli browser
These are the ones I couldn't change the behavior of, in my dotfiles I've managed to fix at least a dozen of programs that were previously misbehaving but offered environment variables to change their behaviors.
The thing that bothers me most about these is that most of these folders are simply cache and logs, I can always delete them and the application will keep working, but of course the folders will be recreated. It's truly mind-numbing.
# Save shell wrapper as '~/.local/bin/firefox'
{ while kill -0 $$ 2> /dev/null; do rm -rf $HOME/.mozilla; done; } &
/bin/firefox --profile $XDG_DATA_HOME/firefox $@
NPM
# set env variable
export NPM_CONFIG_USERCONFIG=$XDG_CONFIG_HOME/npm/npmrc
# and in npmrc:
prefix=${XDG_DATA_HOME}/npm
cache=${XDG_CACHE_HOME}/npm
tmp=${XDG_RUNTIME_DIR}/npm
init-module=${XDG_CONFIG_HOME}/npm/config/npm-init.js
Steam
Steam actually creates only symlinks for backward
compatibility as some games (may) expect them in $HOME.
You can safely launch it with modified HOME variable:
$ HOME="$XDG_DATA_HOME/Steam" steam
(and/or put it into a wrapper script like with Firefox)
Vim
I don't know how it's with SpaceVim,
but with regular vimrc you can make it follow the spec:
https://blog.joren.ga/vim-xdg
What the hell you may have just changed my life. The NPM one I was aware of through xdg-ninja but last time I tried it didn't work because I also use nvm which doesn't support that, honestly not an issue with NPM, I should've noted in the comment. The Steam one however is a total life-changer, if I ever find you in the street someday remember me I owe you a beer (or some non-alcoholic beverage of your preference).
[0] - https://specifications.freedesktop.org/basedir-spec/basedir-...