The dotfiles and dotfolders directly in the home folder is "the way it was always done", and now some "new kids" came and want changes done to software which has existed before they were even born. People have muscle memory for those folders, some have hardcoded those paths in other scripts, others just don't care, and things stay as they always were.
On one hand, it's great to have all the stuff in the same place, on the other hand, we used to have this, before the ~/.config folder too.
Also, it's not just in one place anymore, but in many places -- so to completely remove a programX, it's not enough to just remove ~/.programX, but you need to remove a folder from ~/.config/, and another one from ~/.local/something, and another form ~/.cache,...
So yeah, i understand 'the old guys' too... maybe because i'm not 20-something anymore.
If we want to flex gray hairs, the idea that an application should put it's configuration files in dotfiles cluttering the home directory is regarded as a mistake by the people who are responsible for it.
Obviously, we are now stuck with dotfiles as a "feature", but that doesn't mean we need to have more of them than necessary. Cluttering the home folder with a disorganized mess of files with different modalities next to eachother is ridiculous, pointless, and a collective waste of time.
Almost all of the apps people are complaining about not following XDG were created long after the XDG base directory specification existed. It's time to move on.
P.S.: it'd be preferable also if it wasn't simply implied that everyone who's been around Linux/UNIX for a couple decades hates change. Churn for the sake of churn is bad, but churn is not all wasted. Standardizing once-disorganized directory hierarchy is certainly not a waste of time.
The really fun part is when you have a program that has ~/.programX, but also ~/.programXy, ~/.programX_cache, ~/.programxrc, ~/.programx_init, ~/.programx/a_whole_directory, ~/.otherthing, ~/.maybe_a_database_for_good_measure.sqlite, ~/.and_the_kitchen_sink_too. And that's not even getting into questions like "can I nuke ~/.programX_db to clear the program's cache without losing my configurations?". I agree that the XDG spec isn't an improvement for programs that have _precisely_ one config file, but it's a _major_ improvement for programs that need multiple config files, config directories, separate configs and caches, and more, and it's not a _regression_ from single-file configs.
That's why that kind of software uses a .programX directory, where everything like that can be put in.
Look at ~/.wine for example... config files, whole C drive, everything in one simple folder. Want to upgrade to an alpha version to test something, but don't want to break anything that's now working? Just backup that one single folder. Restore or migrate configuration to another computer? One single folder. Remove any trace of that app? Again, one simple folder.
Want to do the same with google chrome? .config/google-chrome... oh wait, what if there's something in .local too? Still doesn't work? Oh wait, you forgot the .cache directory, and have been loading an old version of something.
Backups are the main reason why I want programs to follow the XDG Base Directory Specification. I don't want my backups to includes gigabytes of files that should be in ~/.cache, which is a directory I never back up. The shell script that I wrote to back up my PC includes dozens of rsync exclusions for files in ~/.mozilla, etc. that should be in ~/.cache.
> Look at ~/.wine for example... config files, whole C drive, everything in one simple folder
Except it isn't really. Just a few days ago I tried to purge Wine from my system. Uninstalled through pacman, cleaned up orphaned dependencies. Killed the ./wine folder and various other leftovers too, because depite your claim, there they were, though I didn't commit to memory exactly where and what. Removed some autostart shortcuts, cleared a few icons from desktop, and manually edited the Plasma menu to remove some stubborn links.
And yet ... I still get suggestions to open my jpg's and png's with something called Wine Internet Explorer. Which i don't really believe is distro specific, since I've seen the same thing happen in both Debian and RedHat derivatives.
If you ever want to prevent this integration from happening in the first place, you can do it by editing the registry in a given wine prefix. You can run regedit with the usual command, `wine regedit`, then locate the key:
Set it to empty to disable the integration entirely. Or, just remove the `-a` switch and you will still get desktop icons, just not file associations.
It is unfortunate that it has to be outside of the WINEPREFIX, but there's no way around it, since those various files need to be in their respective locations to reasonably be picked up. (Maybe it could use symlinks instead, but even if it did, they'd need to get cleaned up by something when the target gets deleted.)
> It is unfortunate that it has to be outside of the WINEPREFIX, but there's no way around it
There is a way around unwanted and unexpected associations though: make the integration opt-in instead of opt-out and/or filter associations that the user is unlikely to ever want (like standard file types that will almost certainly already be handled outside Wine). Wine's Internet Explorer is there for compatibilty with Windows programs that expect IE, exposing it outside the Wine environment does not make any sense.
Since I use multiple prefixes, including temporary ones, editing registry in each one of them is not an option so I have my package manager set not to install winemenubuilder at all.
I believe another approach is to edit the default registry settings in /usr/share/wine/wine.inf so that new prefixes have the desired setting. Of course, then when updating the package it has to be reconciled. But it does have the advantage of being able to allow e.g. the settings that would only produce launcher icons and not file associations. There's another method using environment variables too, though I think that one basically works the same as removing the package entirely and can't be used to customize the behavior.
I kind of agree with you that the defaults are not great, or at least if things haven't changed. We could always see if maybe they'll accept patches to filter out more stuff by default.
This is probably because Wine created a .desktop file in the directory for registering default applications. I don't remember what the directory path is but your package manager is responsible for it, not Wine. They can't put it in .wine because it's a standardised location.
If you have a mass of cached data that shouldn't be backed up would you rather just exclude .cache or investigate what files/directories every individual app uses.
> That's why that kind of software uses a .programX directory, where everything like that can be put in.
You mean, this is why that kind of software should use a .programX directory. Evidently many don't. And of you think about doing it, just move it into .config for good measure...
Crap like wget just keeps shoving files directly into my home instead. When they added hsts support they had the chance to finally create a directory, ideally in .config, so if they need to add even more files in the future they wouldn't have to clutter $HOME even more. But no, that would be too forward-thinking. Just put the hsts file in home and be done.
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).
I don't see the problem. There's no reason to choose one or the other when we can have both. Many programs try several options. Git for example tries ~/.gitconfig and ~/.config/git/config.
Do people seriously resist such non-destructive improvements just because they think it's offensive when younger programmers have opinions on legacy software?
Personally I see a lot of young people use emacs and BSD licences, but because I'm an older engineer and have the wisdom and experience of time, I use vim and GPL.
Another man with the wisdom of ages, irrespective of the date of your birth. Your choice of text editor reveals that you must also be quite good looking.
I'm also a Vim user; in my Vim wisdom and experience I made it follow the damn XDG spec; if hidden files are a feature, I want it to be a feature for my use-cases, not program clutter.
I use nvim like the user (backers.md baby!) so I get to use `master` with `~/.config/nvim/init.vim`. Of course, I also donated to Bram's Ugandas or wherever, so I think you are a wise and attractive person. Your choice of actions reveals that your soul is deep and beautiful.
> Also, it's not just in one place anymore, but in many places -- so to completely remove a programX, it's not enough to just remove ~/.programX, but you need to remove a folder from ~/.config/, and another one from ~/.local/something, and another form ~/.cache,...
OTOH if you want to completely remove your cache, or completely backup your config...
I realize that you wrote "new kids" in quotes, but these "new kids" might have grandchildren at this point given that the initial draft of the XDG Base Directory Specification was published in 2002.
I'd say bashrc and profile and friends are one of the few examples in which using hardcoded paths is OK. Same with SSH, GPG, and PAM.
But when people are talking about compliance, and hardcoding very few people are talking about those applications - there are hundreds of other applications do the wrong thing, and some scripts hardcode things as a result.
No, but don't keep doing it that way for new software, or even new files. You existing config file is in ~ because it's 30 years old. Fine.
If you get to the point where you need another file for something, put it in a directory under .config so whenever you need to add even more, you don't keep cluttering my home.
As a defence of hardcoded paths might go, I could've done better myself. What else from your OS 30 years ago might you keep just because it's 30+ years old?
I keep it because it's worked for 30 years without issues and it's still working. Must you always replace something, just because a newer thing is "out there"? On the other hand, this is hackernews, and rewriting everything, from a text editor to a file browser, into a <language of the week> (ruby, go, rust,...) is a thing.
Try moving all of those directories and files somewhere else that you would prefer and then see which programs break, which apps and libraries won't install, and then wonder why hardcoding is something the devs for these projects cling to.
To be pedantic, if we're going to cite Unix history, then technically there is no such thing as a "hidden" file. As I understand, the original implementation of tools like ls would not show the current directory "." in the listing. The quickest way of doing this in C was checking whether dentry.name[0] == '.'
This also had the side effect of hiding entries that had names beginning with ".", and over time an implementation bug/quirk became accepted behaviour, and was post-hoc rationalised as "hidden" files.
Considering the spec is 20 years old, having "muscle memory" is a bit of a weak excuse at this point.
Having a couple of directories to clean up is a bit annoying, but they used to stick the config file in your home and then make an application directory so we were already having to deal with multiple locations.
On one hand, it's great to have all the stuff in the same place, on the other hand, we used to have this, before the ~/.config folder too.
Also, it's not just in one place anymore, but in many places -- so to completely remove a programX, it's not enough to just remove ~/.programX, but you need to remove a folder from ~/.config/, and another one from ~/.local/something, and another form ~/.cache,...
So yeah, i understand 'the old guys' too... maybe because i'm not 20-something anymore.