Staff dev on 1Password’s developer tools here. We screwed this up in our first few releases of the 1Password CLI, largely out of ignorance. Those releases stored config in $HOME/.op at first. But early feedback pointed us to XDG, so we migrated. Now we check:
1. $XDG_CONFIG_HOME/.op (if var is set)
2. $HOME/.config/op
3. $HOME/.op
I hate to be the dev who says “I don’t know why those other code bases find it so difficult that they put up a fight” but our `findConfigDirectory()` function isn’t exactly complicated, even when you consider all the operating systems that the 1Password CLI supports.
Congratulations, you are in the top 10% for being a professional developer, correcting mistakes and not coming up with shitty excuses.
If people from this thread took notice we all could have a clean $HOME and there would be no need for this non-discussion. As you found out, it is incredibly easy to conform to the spec.
That makes no sense. You should at most have a single directory `~/.config` more and I suppose 90% of the tools writing or reading there could be configured to use ~/.${TOOL}rc
XDG didn't (IMO) make things worse, but it also didn't help as much as it should have. My `~/.config` is the largest subdirectory of `~`, because every Chromium/Electron-based application uses `${XDG_CONFIG_HOME}/$APP_NAME/Service Worker/CacheStorage` and `${XDG_CONFIG_HOME}/$APP_NAME/Cache` (and a few other cache directories) instead of sticking those in `${XDG_CACHE_HOME}/$APP_NAME`.
Exactly. It's never getting fixed, it'd break backwards compatibility now!
It's especially frustrating because it means you can't simply back up your entire `~/.config` (or wherever you pointed your `${XDG_CONFIG_HOME}`), you have to pick specific files & folders in there.
I considered it clean when everything had a single file or directory in $HOME. Some things didn't play nice but they were the exception. Now it might be that, or there might be files scattered among one or more XDG directories.
You cannot redefine words to the opposite meaning. If you want to lump everything together then Linux is not your friend.
On Linux we separate stuff so you can for instance backup config without having to figure out for each of 100 applications where they have stored config in 100 heaps of mud.
And you are sidestepping the issue of control. With XDG you can easily and generically symlink your 100 balls of mud back with 3 lines of bash. That's because with XDG you have structure. The other way around you don´t. So don´t talk about `clean`.
> You cannot redefine words to the opposite meaning.
I'm not. Lots of things in a directory is not inherently a mess. I mentioned exceptions, things such as bash and steam make a mess because they're not completely cleanly filed away in their own directory. In my experience most things (not all) that don't use XDG are happy to cleanly files their stuff away in its own directory, sometimes divided up further into subdirectories when it makes sense. Or a single file instead of a directory if there will only be one file.
> If you want to lump everything together then Linux is not your friend.
I don't need to be friends with a kernel, and anyway, this practice has been around on Linux longer than XDG has existed. I see no reason why it won't continue to work just fine in the future.
> On Linux we separate stuff so you can for instance backup config without having to figure out for each of 100 applications where they have stored config in 100 heaps of mud.
People use Linux in different fashions. You're free to use it how you want and I'm free to use it how I want it. Your backup scheme is not suitable for me, and I suspect mine is not suitable for you. And that's OK.
> And you are sidestepping the issue of control. With XDG you can easily and generically symlink your 100 balls of mud back with 3 lines of bash. That's because with XDG you have structure. The other way around you don´t. So don´t talk about `clean`.
Most applications in my experience have a mechanism to define where configuration is read from. That's control, not your symlink mess. Structure is done appropriately per application.
It's fine if you disagree with me. It bothers me when I'm told that my opinions are wrong, which is what your post reads like to me.
And yet you impose XDG (originally a GNOME specification) on macOS (completely unrelated to GNOME or Linux). On macOS, you should be looking in ~/Library/Application\ Support/op and ~/Library/Preferences/op/config.
I’ve got a script that I’m making conform to XDG, and it's a lot of work to make it work well because I have to know about three different roots for different things (configuration, temporary files, and persistent files). I’m not convinced that it's worth it, because it is no longer as easy as telling someone "uninstall this by doing `rm -rf ~/.PROGRAM`", but instead I have to say `PROGRAM self destruct` or something like that to clean up all the detritus (and what if it fails in the middle?).
I'm pretty sure the XDG base directory spec was not specifically a gnome thing. It came from freedesktop.org[1] if I remember correctly, and in fact gnome was not compliant to begin with[2]. That gnome wiki page references that the recommendation (which turned into the spec) came from freedesktop and documents the gnome "initiative" to become compliant. Freedesktop was focussed on compatibility between desktop environments and systems, so isn't just a linux thing.
As macOS user, I'd rather they use XDG than the "standard" macOS directories. Maybe there's a point to be made to use the standard if the XDG variables aren't set, but I'd generally avoid that for CLI apps. Having everything under ~/.config is more convenient.
Agreed. "Application\ Support" looks subjectively disgusting to me. It's the only path on my configuration with spaces. I have to use it because that's where vscode settings.json is placed.
If it helps, it may have been for a good reason. Microsoft used to name the folder that stored user directories "Documents and Settings" so developers would be forced to make sure they could handle paths with spaces in them. Now, they call that folder "Users", and I had to make sure when I set up my Windows install that my name didn't have spaces in it so a bunch of apps didn't get screwy.
Big +1, macOS has a lot of UX wins, but their config directories aren't one. Also XDG allows me to have at least some things in the same place on Linux and macOS, which may be a very niche need, but still something I appreciate.
+1 to this. I have been a MacOS-exclusive user for more than a decade now and `~/Library/Application\ Support/` is simply ugly and, dare I say, un-Apple like. It has a Window's "My Documents" vibe going on.
Xdg isnt just config. Using .config (xdg config) on Mac is super weird.
Xdg is also, .cache (xdg cache dir) for data that can be cleared on reboot allowing you to use tempfs for it (of course you can't because a bunch of shit uses it as a persistent cache for things they should be putting in .local/share/. (Xdg data dir).
This whole mess is so utterly fucked I gave up caring and just let the mess be.
> Using .config (xdg config) on Mac is super weird.
Why? Using it makes macOS more similar to Linux, which I think is a good thing. It surely makes it easier to share configuration files between Macs and Linux machines.
Honestly, I don't see a single upside to using macOS's specific directories over .config/.cache/.local.
There are operating system processes in place to help keep `~/Library/Caches` smaller (or at least somewhat constrained). They are not there for `~/.cache`.
I don't see anything saying that clearing ~/.cache on every boot is expected behavior. I see lots of real world behavior of using ~/.cache as a multi-gigabyte download cache you would not want to lose regularly.
Most prsistent files should never be cleaned on uninstall, you don't know why they're uninstalling, it could just be a reinstall to fix something. Configuration might not need cleanup either.
Temporary files often shouldn't exist. If it's less that a few megabytes why is it touching disk unless it will be needed persistently? In any case the detritus doesn't matter, if it's big enough to care I'll see the disk space is low and find it with baobab at some point.
It's not perfect, but it's not a major nightmare.
For my part, I don't always follow XDG specs, I often just create ~/AppName, but sometimes I'll make more than one to keep features within one app separate. I put IP cam recordings in ~/NVR by default, and stuff like that, because the main app dir is all stuff you would backup and restore, which probably doesn't include NVR recordings for a home user.
Has a MacOS dev, I'd prefer config like this in my home directory so I can easily access it between MacOS and Linux. My expectation for CLI tools is that config is in $HOME/.config/.
Yet…that is exactly the argument of the original post. The banner argument is that VIM is wrong because it doesn’t use `~/.config/vim` and instead uses `~/.vim` … which it has used since before XDG was created. Vim also doesn’t use ~/.vim` on Windows (and the files aren't `.vimrc` and `.gvimrc`, but `_vimrc` and `_gvimrc`.
User expectations differ. The correct place to put application detritus is `~/Library` on macOS (`/Library` if it’s system-level with no user-level). I am surprised when a cross-platform library uses `~/Library` instead of XDG, but I am not unhappy with it.
Frankly, most programs should have a command like `show-config-paths` (`--show-config-paths`) so that you can see where the configuration, caches, etc. are on the platform you’re on, and possibly be told (a) whether they are overridden from default and (b) how to override them. It would be useful to have that output for both human and machine reading.
I agree 100% on having a command to this effect. I always make sure that there is a command to show the currently resolved configuration location, as well as printing out configuration (minus secrets) when the application starts in debug mode.
Furthermore, when you do '--help', whenever it's half-way reasonable, I will show you what your currently resolved settings are for any flags/variables/configs next to the corresponding flag, as well as the default value. I actually don't know why this isn't common.
Yes. I think that the plugins should probably not be in $XDG_CONFIG_HOME, but in $XDG_DATA_HOME, if I’m reading correctly.
But in part my point is that there's virtually no one who gets this correct either with Linux systems or macOS, which is what makes rants like the parent article so annoying.
The XDG config/data spec was made to manage systems that mount over NFS; ~/.local would stay on the local workstation, ~/.cache matters so little it could be on tmpfs, and ~/.config is the permanent romaing storage (and being config, could be on a slower server than the rest of $HOME). Quite a lot of programs don't ever care for these distinctions. "All in ~/.config" or "all in ~/.local/share" are both common and both wrong (programs that do this usually ignore that ~/.cache exists). Sometimes they're split over seemingly arbitrary and nonsensical reasons, and are inter-dependent enough that you have to really double check all three locations if you want to clear or modify a program's config outside of the program itself.
All of this is just a nightmare and I much prefer the simpler ~/.program or ~/.programrc approach. It's findable, it fits perfectly fine in the non-NFS use case, and just stop running "ls -A" on every invocation.
(Sadly, the Windows stuff really screws up running games through Wine, since it will default to connecting the Windows "Documents" to ~/Documents and ... ick. I disable this feature in Wine just to make it separate. They can muck up Wine's Windows folders as much as they want, it's invisible to me.)
$HOME is for my documents, don´t pollute it with 30+ .$program folders please. Can we as users have just at least one sanctuary place for our own docs that will not be messed with by stupid programs?
The XDG spec is so simple, if a software developer still lacks the mental capacity to adhere to it he/she might be better of finding different hobbies. Come on now.
So instead of 30+ .$program directories (not folders please), you get up to 120+ directories of the form .cache/$program, .config/$program, .local/share/$program and .local/state/$program ?
I'm not convinced that one is unequivocally better than the other. For me personally, I prefer a flat namespace to having to hunt down directories in a tree of varying depth.
I manage $HOME, this is meant for valuable personal documents. I manage them manually. You as a software distributor better are not gonna clash with what I am doing there with your shitty engineering.
If you insist on making a mess of your $HOME, XDG allows for that. You can set all your XDG variables to $HOME. And even without doing so, you can create symlinks to make your $HOME like you want. That is an unfair advantage you get with XDG adherence.
XDG gives you as the user more control. If you don´t adhere to XDG, you take that control away from the user.
I have to disagree here. XDG is a poor spec. It makes assumptions about structure that may not hold. If I want all my config, cache, and local stores in per-program directories, XDG makes that impossible. If I want a specific program’s config directory somewhere other than the XDG setting, that’s not possible.
You complain XDG makes assumptions while we are discussing software that makes the assumption that $USER has no say over $HOME. At least XDG is user configurable.
XDG allows for a superior partitioning. If you don´t like it, you are likely to complain about Linux as well. XDG separates config, run state, cache and data, which is quite reasonable for a Linux system as that is what Linux does.
---
> If I want a specific program’s config directory somewhere other than the XDG setting, that’s not possible.
1. $XDG_CONFIG_DIRS even allows for more multiple paths to be searched.
2. You could even override XDG-vars per application in a launch script or in the shortcut.
> If I want all my config, cache, and local stores in per-program directories, XDG makes that impossible.
You can set all the relevant $XDG_vars to $HOME and all your foo stuff ends up in $HOME/foo. Or symlink from $HOME.
The XDG world gives you options, while the non-XDG world doesn´t.
---
XDG could have opted for user overridable utils instead of variables. But you have already lots of options now.
Your documents should go in ~/Documents, not directly in ~. Also XDG is is specifically for X11 applications. I don't see why ones without a GUI should respect it at all.
> Can we as users have just at least one sanctuary place for our own docs that will not be messed with by stupid programs?
What about $HOME/Documents? But yeah, I hear you, I gave up on $HOME as my personal space, I put my stuff in /data (I use my computer alone) and let any software pollute my $HOME.
.local and .config are 2 directories instead of 30. We make the problem managable.
If you want to create a mess, you are free to do so with XDG variables. Read my other comments for that.
Stop pissing in my $HOME and don´t tell me I should have no problem with that. Just adhere to XDG, $HOME is for me and I decide what I want there. You don´t.
No, XDG limits it to __2 known names__ in $HOME, versus __infinite unknown names__ in $HOME for non-XDG.
If you want to shit around in $HOME, you can make symlinks from $HOME or set your XDG-vars to $HOME.
In the non-XDG world we don´t have that control. Such software shits into $HOME, and it sticks there because it refuses to listen for user preferences (XDG-vars).
As a user that deals with non-xdg software I don´t have control on the one directory that was meant for ME.
--
The only improvement I can think of is that XDG would provide functions that software could call into instead of vars to get dir paths. That way, the user could have very fine control (even per application) when they write their own bash override.
My settings documents are also my documents, so I want my ${program}rc to be right there too. I don't install 30+ stupid programs so I don't feel polluted, that's so simple.
I find the split into three directories useful for different reasons. I keep .config in a VCS. I include .local/share in periodic backups. And I don't backup .cache at all.
Programs that put everything in .config or .local/share mess that up.
>The XDG config/data spec was made to manage systems that mount over NFS
Which makes sense in theory, but the execution is horrible. The ~/.cache directory is also on NFS now... You NEVER want cache on NFS.
>~/.local would stay on the local workstation
Never seen this in practice. This dir is also created on the NFS share, which it should be, since you need to bring these files to other machines as well. The standard is poorly thought out and poorly implemented.
It's the rationale behind the XDG directories, nonetheless. The "ideal" setup is to have ~/.config on the remote NFS server, ~/.local on the local workstation, and ~/.cache on the local workstation (either disk or tmpfs).
And yeah, poor implementation means that ~/.local not roaming around with you just makes things worse, despite the obvious name and intention. Developers almost never know when to properly implement it.
XDG is just overcomplicated nonsense. The only part I like is ~/.cache. I don't buy for one bit the "clutter" argument about having some dotfiles (and no, setting $XDG_CONFIG_DIR=$HOME and $XDG_DATA_HOME=$HOME does not solve it; first, conflicts; second, files won't be prefixed with a dot).
Why all the moralizing? Deciding when to make breaking changes is hard. Deciding it's more trouble than its worth for the developers and the users usually shouldn't be ascribed to one of "ignorance, arrogance, or fear". It's just an engineering disagreement.
I'm trying really hard not to end this flippantly with "go touch grass" but I think the mood fits. Escalating appeals to emotion are unhelpful and "cringe" when trying to convince open source developers to add your pet issue to their roadmaps.
No moralising here. I'm directly calling out developers who are completely okay with writing thousands of lines of code from scratch for a fancy new feature, but can't be bothered to directly lift proper directory handling code from other open-source projects and reuse it almost verbatim.
Like I said: it's easy to just dump stuff in $HOME. It's a lot harder to properly handle paths, but it should be done anyway to be a good citizen. Ideally: check for a legacy path; if it doesn't exist, check for XDG paths; if that doesn't exist, create and use XDG paths. If a legacy path exists, notify the user of a migration and either warn them to do it, or attempt to do it for the user.
I really wonder how many programs will immediately break if I suddenly set my home directory permissions to 0100.
How is lampooning people who disagree with you as "arrogant" not moralizing? Arrogance is a moral accusation.
This isn't a problem where you can just copy and paste a deductively-proven-correct-for-all-inputs solution and be done. One way or another you're creating problems for existing users and existing scripts as soon as you start using the new location. A newly provisioned system with an old script (or an old user (and "old" meaning nothing more than "older than this change")) running on it is going to end up thinking that it's doing a create-or-modify on, say,`.bashrc`, when in fact it's doing an override (because existing config was in the new location).
"Ignorance" is being blind to that problem (and others). "Arrogance" is pretending like it's somehow obvious that that problem isn't worse than the benefits of unifying on this convention, especially when there are so many examples of estimable projects on both sides of the issue.
The arrogance is pretending that user configs and wishes can be arbitrarily dismissed because you can’t be bothered to adhere to them. My computer is mine, not the app maker’s.
You're assuming your concerns were dismissed arbitrarily. Why? Is it possible that your concerns were considered, pros and cons were weighed, and the final decision was simply not in your favor?
And what's this nonsense about "my computer, not the app maker's"? How do you think project governance works? Decisions are made, and every single time a subset of users are disappointed. That subset isn't having control of their computers taken from them. This stuff is happening out in the open, for free, and with express permission to override any behavior you want with your own patches. You can even distribute your patched version, also free of charge. It's downright humbling how free we are when it comes to bash and OpenSSH, and you have the gall to come out with "My computer is mind, not the app maker's"? Do you have any idea how low the bar is for user respect in the average app? How much money can be made if you're willing to disrespect your users? And the bash and OpenSSH folks would never, not ever consider any such breach. They have stayed firm, despite world-blanketing success, in their user-respecting free software ways.
And for a disagreement of where to put config files, you'd lump them in with the user-hating rabble that makes up the rest of the software industry. We're surrounded by people who actually do arbitrarily dismiss user concerns (because the users are the product). People who actually do believe your computer belongs to them when you use their software. Please, in the middle of all this shit, keep in mind who your best allies are and just have a civil engineering disagreement with them, without insulting them.
As has already been pointed out, plenty of existing scripts and users know that SSH keys and other configs are in $HOME/.ssh/. If OpenSSH moved to XDG, such a script or user would come to a new machine using XDG and not be able to find the SSH configurations. A user might be able to learn where they are, but a script wouldn't. Similarly for .bashrc.
Given how often tools like bash and ssh are used programmatically and not just interactively, it is very much conceivable that the right choice, the one that brings the least amount of harm to their users, for bash and OpenSSH is to stick to their existing conventions forever.
I should also note that $HOME/.program-name is very much a community standard that the XDG people decided to move away from. Or at least it used to be.
The way I handle it on my systems, certain programs such as ssh and bash get "special status". They are so deeply fundamental that they get a pass when I gripe about .rcfile proliferation. You get .ssh/, .netrc, and .bashrc, I'll allow it.
That doesn't mean every .dumb_tiny_cli_rc gets to do that as well.
> I should also note that $HOME/.program-name is very much a community standard that the XDG people decided to move away from.
So was every single inferior standard or convention, before it was replaced by a better one. It's called progress. It's a balance between improvement and breaking changes / disruption, but you need some improvement over time.
The poster above was making two claims that I responded to: 1, that apa writing their configs in dot files under $HOME is "breaking community standards", and 2, that there is never a good reason to do so.
Have you never worked on a legacy product with lots of paying customers? The not-so-hard to imagine case is where updating your code to be Pure and Wonderful would have a negative impact on thousands or millions of existing deployments.
Honestly, I see some arrogance here but not where you put it. Just like your computer is yours, the developer owns their application. Use it or not, but don't blame them for arrogance if it does not behave exactly like you wish.
Then, by using XDG variables, the user can get precisely what they want, but only from those programs which follow the XDG spec which is designed specifically to enable user control of the locations where files go.
Some here complain about a convention (not using XDG vars) which removes user choice. Others here recognize that the convention to use XDG allows for user-defined configuration.
If a user's wish is different from the XDG default convention, they can change its configuration. If a user's preference is different from the $HOME/.$program convention and the maintainers don't use XDG vars, the user is SOL.
Most users don't care because they do the same with their own files.
The xdg standard just introduced 3 additionnal .config .local .cache directories that do not solve the presence of the regular .dot directories/files. It didn't solve anything, just added more mess. Besides the stuff that end in .config is as messy as what was in ~/.dotdirs. I once was naive enough to think I could put my .config into a git repo...Quickly enough you realise that a lot of developpers put what the fuck they want, including stuff that should be in .local or .cache into .config and you end up writing a novel in your .gitignore.
XDG didn't solve that, it just added additionnal mess, which I didn't wish for.
If it was to end with that mess, I'd rather have it the old way and keep mt dot files at the root and separate my own files into a dedicated folder, and I AM THE ONE to choose if it has to be called files, documents, docs, translated or not, not some people pretending it built a (broken) standard that would solve every user needs.
> Most users don't care because they do the same with their own files.
Maybe I'm not most users, but I absolutely put my files in ~/.config/$my_namespace/
> It didn't solve anything, just added more mess.
Have you ever had to migrate/sync parts of a system across multiple hosts, or even just backup with very limited space and having to be choosy about what is stored? XDG makes it WAY easier to set up rules to include/exclude stuff, than a bazillion .programrc dirs (which make no config/data distinction). Cache can be completely ignored and usually (the more voluminous ) program data can be skipped. The app will usually generate it as needed, and if not, I know what to sync.
Every program and their dog barfing in $HOME is something I didn't wish for.
You computer is yours …and you are not forced to use maker's app. Well sources are opened, so you can change things to suit your needs instead of considering makers as your slaves can't you? :)
You’re making a lot of assumptions here, like that paths to config files are used by only one program, or that there’s an interactive way to prompt a user on every run, or that XDG’s extremely limited config options suit every user’s desires. Sorry, but this is not an “easy” problem, especially not for existing widely used tools like OpenSSH.
Yeah, let's break the entire world in order to bring OpenSSH up to ideological purity (as defined by a particular group, to the exclusion of everyone else). XDG, or now Free Desktop, have no authority to dictate how others write their software. What makes their prescriptions holy? We are all equal in OSS and no one has the right to enforce their ideals on others.
I myself simply want the software to work and not to suddenly change behaviour. If you're writing something entirely new, perhaps the holy edicts of the XDG are right for you. But to ask for OpenSSH to change shows a complete incompetence in software leadership and impact assessment. Anyone that suggests something that insane ought not to be listened to and all their ideas ought to be entirely disregarded.
I keep a small series of patches for various software on my system, to fix, or at least relocate, config files to XDG locations[1]. I do this for applications I care about keeping their state. For other applications I either set the environment variables or remove the dirs on login[2]. Of course, the complexity of the project and my familiarity with the language also affects whether I bother with it. Not gonna be able to change ~/.cargo or ~/.dotnet soon (unless someone has patches for those?)
It's buried in my gentoo config, but I wonder if there'd be a good way to make this useful on other distros.
My own solution on windows is to make a separate folder such as c:\users\redadmiral\Documents\files and have my documents live in there. Then I make my own start menu / taskbar shortcuts that point to that (I have Win+E set to open "My Computer", as I use USB drives a lot, and have pinned the folder there too).
That way, I accept that the (My)Documents folder is full of other programs' crap, but the "files" folder is MY PRECIOUS and no-one but me decides what goes in there.
Before this, when I wanted to remove a program's detritus from my disk, I did rm -rf $HOME/.program
After this, it's an easter egg hunt to guess what dot-directories got spammed.
As far as I can tell, the XDG spec only benefits people who care really hard about how many hidden files are in $HOME. It definitely breaks behavior for people who DO want those per-app directories/files in $HOME, because the XDG spec does not mandate that the files created under e.g. .config/ are dotfiles themselves. So setting $XDG_CONFIG_HOME=$HOME just creates non-hidden files in the home directory.
At no point in this article is a technical justification made for this rigamarole, but this article goes to great lengths to accuse people against it of cowardice, ignorance, or arrogance. Just... why?
With XDG a program's user files are split into pieces with varying degrees of detritusness. You generally only have to look in four places in ~ when cleaning up after a program called foo:
- ~/.config/foo -- only you write files here, so it's your detritus, not the program's :)
- ~/.cache/foo -- this is non-essential cached data, by definition detritus. Go ahead and clear out all of ~/.cache whenever you feel like it
- ~/.local/share/foo -- this is the program's user-specific data, data which it may have created or which you may have created. Whether it is detritus is up to you
I think the strongest justification for XDG is that it makes it stupid easy to configure backups so as to exclude cache files. And the separation of config from data also makes it easy to keep a git repo for all your ~/.config files.
Files describing how to do IPC with current processes. They belong to ~/.local/state not .config.
This time, I won't even try to make a judgement as to what is "my detritus" as opposed to the program's because there are too many files involved, and will just show how much they occupy on my drive despite being in .config when 90% of them really ought to be in .local/share and .cache
> cd ~/.config/google-chrome
> du -h
> 999M .
Ahem. I think the idealism toward the XDG spec has not panned out.
By the way, Chrome does have folders in .cache :
> cd ~/.cache/google-chrome
> du -h
> 651M .
But, I believe it doesn't put "local storage" stuff from webapps there.
It doesn't use ~/.local at all.
~/.config is broken beyond belief and not the place where you just have "your config files".
The only sane way to manage "your config files" is to put them in a git managed folder and use a symlink farm program.
It's a misunderstanding that only the user writes to config. It is meant for persistent user configuration, possibly generated by the app - the type you might want to back up. You are not supposed to understand or be able to read every file in there, just be able to know the usage.
.local is rather new, so .config has been misused for what was meant to go there. Some applications are broken and stuff caches in there (Google stuffs shader caches in there it seems?), but minor misuses is one thing - .config and .local are conceptually very close for example - intentional disobedience another.
The spec is well adopted (I have hundreds of folders in ~/.config, only tens in ~), and there is no reason not to follow it - especially for cross-platform things where path logic must already exist. There are just some projects that decide to stubbornly go against community and user wishes and disallow improvements.
>It is meant for persistent user configuration, possibly generated by the app - the type you might want to back up. You are not supposed to understand or be able to read every file in there, just be able to know the usage.
I understand your point, but there is a lot more going on than just "configuration that isn't human readable" unfortunately.
> (Google stuffs shader caches in there it seems?)
They also stuff web storage.
And despite their misuses of .config they also still pollute the root $HOME by creating $HOME/.pki. Deleting the folder and restarting Chrome will always create this thing.
> At no point in this article is a technical justification made...
> Just... why?
Author here; I was under the impression the quote from the Vim issue tracker in §3.1 was a good cornerstone for the article, which is that accepting and implementing an existing standard—however hard it might be for developers now—is good for users in the long term, because it makes life easier for them.
And therefore developers should try to adhere to the standard even if it is difficult to implement, since software is written for users, first and foremost.
> Author here; I was under the impression the quote from the Vim issue tracker in §3.1 was a good cornerstone for the article, which is that accepting and implementing an existing standard—however hard it might be for developers now—is good for users in the long term, because it makes life easier for them.
In my opinion, ~/.something is easier for me as a user than using the various XDG directories. But in practice, I really don't care what scheme an application uses.
The XDG spec gives YOU as the user CONTROL to get it like how you want it to be. That is why you can set the $XDG* variables, so that the software listens to your wishes.
Without XDG adherence, software packages just piss all over the place, wherever they like to.
There are programs that even manage to create multiple dirs, like .something1/ and .something2/. Some other programs are even worse and put files just into $HOME. Good luck with backups.
With XDG adherence applications might comply and put files scattered around the various XDG directories. Before XDG, applications that pissed all over my $HOME were rare, applications generally played nice and kept only on dot file or directory.
Backups are even harder now because I have to cherry pick what to backup from even more places. I don't backup all of $HOME because it's loaded with junk I don't want to waste backup space on.
As another user, I do care, and I dislike the XDG directories. ~/.local/share/foo in particular is obnoxiously longer than ~/.foo, and the existence of the XDG spec means that if I don’t know where a program stores its files, I now have to check three possible locations (~/.foo, ~/.config/foo, ~/.local/share/foo).
Now I have to scan whenever ~/.foo/tmp, ~/.foo/cache, ~/.foo/cef/Cache or whatever hell has the useless uncompressible, duplicated and always changing data to exclude from backups and synchronization, for every program that fills random dotdirectories.
I find it easier to exclude all .* from the rsync I do to synchronize documents/data etc, and exclusively manage the dotfiles through another program, homeshick, where instead of making exclusions, I make explicit inclusions. The config files I care about are far, far fewer in numbers than the random crap programs spew in dot folders.
I like the XDG specs, but even programs that pretend to follow it don't follow it. CMUS, a music player, moved into ~/.config.. moved everything, including files that belong to .cache and .local/state. Google Chrome has 999 mb worth of files in its .config folder on my computer.
The truth of the matter is that XDG only managed to encourage developers to move their files away from the root of $HOME but they didn't manage to make people respect a proper hierarchy of files.
> The truth of the matter is that XDG only managed to encourage developers to move their files away from the root of $HOME but they didn't manage to make people respect a proper hierarchy of files.
This is a great point, honestly. XDG actually does specify where things are supposed to go, and distinguishes between config, cache, state, and strictly-user files, but devs don't respect that hierarchy, either.
Apps dumping cache/state into ~/.config/myapp/ is still better than ~/.myapp in the vast majority of situations. I can still usually afford to sync / strongly back up ~/.config even with a few bad apples barfing heavyweight cache/data there (and I can always use ignore rules), while syncing all of $HOME is just a nonstarter.
> I can still usually afford to [backup huge caches incorrectly placed into ~/.config], while syncing all of $HOME is just a nonstarter.
I completely fail to understand this viewpoint. The non-config files that I intentionally put into $HOME are infinitely more valuable than anything I would want to backup from .config.
I have hundreds of gigabytes in non-hidden sub-directories of $HOME, such as all my family photos, all my health-related documents, all my email, and so on -- and they are backed-up every single day.
Why is backing up your actual files in $HOME a non-starter? What makes your .config more valuable than everything else in your $HOME?
As another user, I find it infuriating that 95% of all applications I run respect XDG and go into ~/.config (where I have hundreds of folders), but a handful or two do not and litter in my home folder.
If only the last stubborn applications would comply, I would have just 1 place to look for config, and one place to wipe caches.
Plenty of apps which use .config use it for everything, caches included. The percentage of apps which fully respect the XDG spec is much lower than the percentage that use the XDG config dir. And this is to be expected - changing the default config dir is one thing, changing your code to put different kinds of files in different places is much more work.
Not really - since XDG decided to go for non-hidden files inside the XDG dirs. So you can't just set your XDG config dir to be your home dir, since all the app config folders will be non-hidden folders in your home dir. And setting up multiple XDG dirs to point to the same dir will probably cause even more havoc, if apps use the same file name with different meanings in different XDG dirs.
Many apps that claim to respect XDG…don't respect XDG fully and mix executables, config, temporary files, and persistent files in some combination of the spread of XDG directories.
The position is clear, but I don't think it's a valid position. If I, the user, want my dotfiles to exist per-app in $HOME, the way they have since I started using UNIX in the 1980s, I have no recourse. Not being able to configure the location of config files to the place they already were in the name of "user choice" is incoherent at best.
A fellow commenter pointed out that it makes excluding cache files from backups much easier. That is a great technical justification, which hilariously does not apply to vim, which by default drops swapfiles in pwd anyway.
I further reject the notion that this is something being "done to the user" by the software. Software is a tool of the user, refusing to learn how the tool works and pretending that the program you chose to execute is some kind of rude houseguest is just wheelspinning.
I know it's configurable; that's why I included the phrase "by default." The linked issue does not address this.
And I'm not sure, maybe you just didn't read the rest of my comment, but in it I explain that when XDG people get what they want, it becomes literally impossible to configure the software to revert to the previous norm. In other words, when XDG people get what they want, nobody else can.
I'm not sure I'm following you. What state are we considering to be "what XDG wants"? If it's just adding XDG as an option for where config is, then that's fine. If it's replacing custom config location with XDG only, then I would certainly agree that they are unduly influencing things.
It depends on how XDG dirs are handled by the software. If we're forced to use the env vars then it's not really optional anymore. But if the program can default to another location without those env vars set (trivial with an ldpreload script or something), then it supports both.
Vim can be configured to use XDG dirs, if you really want to. Does Neovim limit users to only XDG for its config? I can't think of many pieces of software that outright force XDG. Maybe GNOME stuff?
Every software that follows XDG-basedir stores config in ~/.config if the env var isn't set.
Imagine you have program "foo" which has config, cache, and so on. What XDG-basedir env vars can you set to make it use ~/.foo for all of that? If you try, then because software following XDG-basedir probably doesn't anticipate that XDG_CONFIG_HOME and XDG_CACHE_HOME might have the same value (and because your time is more valuable than auditing the code to find out whether they did anticipate this), you are left with .foo/config, .foo/cache, and .foo/local.
You have created a new "home", and, more importantly, you disallow "foo" from ever spawning a separate program that also uses the same XDG vars. Spawning programs is rather a central Unix principle if you have many tools that each do one thing well.
If you want an application to use a directory all to itself, you can set $XDG_CONFIG_HOME when running that program. Some software has no facility to choose the location of configuration and cache files at all; this specification at least ensures that the user has a choice.
While I strongly support the idea of allowing users to control the location of their config files, I don’t really like the XDG spec, specifically the part where setting nothing ends up putting files in two or three disparate directories.
Also, it’s not “respecting your users” to change where their config is stored without giving them an option. Were OpenSSH to implement XDG, I may want .ssh to remain where it is, but the XDG spec would give me no way to specify that preference. Certainly a lot of tools would expect to find .ssh in $HOME but wouldn’t. And the systemd integrated stuff expects an active user session, which is not always going to be the case.
Sorry to say that it’s typical for folks like this to rant about respecting users while completely ignoring whole categories of use cases and insisting on breaking long-standing behavior for their own aesthetic sense of consistency.
Apple tries to fight this by providing ~/Library as a place for applications to put whatever support files they need, but there is still a shit-ton of garbage dumped in ~/Documents by various applications. The fact that ~/Library is hidden by default probably doesn't help make it an attractive place to put all the junk your app generates.
Personally I have largely abandoned ~/Documents and keep all my work in a sub-directory of it that's under my control.
Genuine curiosity, do I understand it correctly you specifically make a sub-directory under the default ~/Documents directory for the purpose of managing your documents?
I don't find this weird or unusual at all, just different than how I've handled file management on computers since I was a child using the family computer; I did notice the way computers stored program data when I was first learning computers and while I had a vague understanding of how programs worked, the conclusion I came to as a child was "just don't mess with the stuff the OS uses and make your own folders instead."
Usually I have my personal documents in some folder(s) under / or on dedicated drives, separate from the OS/program directories entirely whenever possible, and I treat any pre-existing folder structure as "the OS' and programs' folders" and just don't use them at all (with the exception of ~/Desktop and ~/Downloads which more or less I use normally) I understood early on that developers might make their workspace just about anywhere so I don't particularly care about the system defaults and instead try to keep my data in its own location outside of any system defaults whenever possible. The before-mentioned ~/Desktop and ~/Downloads I treat just as temporary directories for me and fair-game for other processes, so my workflows specifically don't keep any personal or sensitive data in common system directories.
I did not ever specifically do that. If I was starting up a new digital life now I would probably do that. But when I started using OSX, I made a few directories in ~/Documents (before it became apparent that every program under the sun was going to have a chance of shitting something in there, and the vast bulk of what I do lives in one of those directories.
(Actually, it lives in a sub-directory of one of those directories, with a disused organizational scheme lurking around it, but, well, if you want more details on that there's a whole blog post: https://egypt.urnash.com/blog/2019/01/06/how-i-work-file-org... )
Back on the Amiga I had something like four partitions on a then-massive hard drive, one for the OS, and three for My Stuff, which I managed however the hell I pleased. But that's not really an option on a laptop.
Wouldn't it being hidden make it much more attractive? You can put junk it in and users won't complain, and if they do want it you have a help article on your site.
I remember asking a games porter (from Windows to Mac) once why they put savefiles in the Documents folder instead of Library (some older games of theirs did put them there) they replied that because after Mac OS X changed the Library folder to be invisible they had people contacting support being unable to find the savefiles, so they put it in a place where it was visible.
I'd expect the "less attractive" part is for when you do want users to find the data your program creates in general.
That's an interesting use case. I guess there's a class of users who are smart enough to want to manually copy/backup files but not smart enough to know about hidden folders or standard directories. Windows has a similar situation with its hidden AppData directory, and Unix with its hidden dotfiles.
I hadn't given this much thought but now I am disappointed that the people who came up with these standards didn't do more UX research and trial & error with actual users. Perhaps if they paid attention to all the use cases and stakeholder needs it wouldn't be such a mess.
No, because part of the point of all of this is “how do I move my config to other computers, or manage it across multiple computers at once?” Hidden “junk” gets lost, is hard to support, etc.
Even within ~/Library, there is organization. In the lists below, $app is either the application name or the application id (e.g., `lazygit` or `com.foo.bar`).
- ~/Library/Application\ Support/$app - sometimes used for configuration, sometimes used for support data, sometimes for other things entirely (including caches, but that is the wrong place); probably similar to $XDG_DATA_HOME.
- ~/Library/Caches/$app - equivalent to $XDG_CACHE_HOME.
- ~/Library/Logs/$app - no direct equivalent, but ~/.local/var/logs.
- ~/Library/Preferences/$app - mostly $XDG_CONFIG_HOME, but $app in this case could simply be a single plist if that's all you need.
I mostly find myself annoyed when command-line apps use those directories, because it makes shared configurations between Linux and macOS that much harder, even with chezmoi. At the same time, respecting that over the non-native XDG…is what this article is about, no?
Not that the author gives any time to macOS except an ignorant swipe at macOS windowing (you don't like it and you're not used to it; that doesn't make it wrong).
Part of me thinks the solution to some of these trenchant apps is to make a FUSE pass through filesystem driver that has silent redirects. Don't report .vim or .ssh in directory entry lists. But if someone goes to open the path, silently redirect them to
.config/ssh or whatnot.
I really want to have a home that isn't a clutter filled hell. Same thing with code repos. To me, the source is the first & most important thing. I want foo.ts at the top level. I'd opt to put all the buildconfig stuff in .config.
Huge shout out to the list of issues ld-preload-open documents. Really great to have gathered such a laundry list of topics, really expands the technical knowledge of the audience by showing off a lot of interesting interaction points between app & os.
Not supporting any "at" variants (like openat) is a pretty big one! I bet a lot of these could be tackled with a lot of work to track state, but some like symlinks not working well since they're handled at the OS level seem hard to imagine overcoming.
FUSE would definitely have some issues too, but I think a lot would go away.
I think this whole rant is the ‘arrogant’ they’re talking about. I think a lot of authors have a perfectly good point when they say they don’t need the complexity, or want to stick to many decades long conventions.
And time and experience has shown that it is a subpar solution, especially when $HOME/.myapprc is effectively hardcoded, so you can't even reconfigure it, you gotta use links.
My point was that apps that put dot files in $HOME are following a convention. You can argue that XDG is better or that it's worse, but you can't accuse the app developers of ignoring conventions in general. It's not like OpenSSH creates its own dirs in / or something.
There is complexity in making the change and diverging on different platforms. ~/.myapprc was there first and it was XDG that came along and wanted everything to change.
Would love to see examples for Rust, Go, NodeJS, C# and Java so that I can add them to my GitHub stars. I could find a few results for XDG support in Go, Rust, and NodeJS, but none of the aforementioned languages supported standards across all of macOS/Windows/Linux. Hopefully it's just my Google-fu failing me and people can correct me in the comments?
C and C++ still have strong roll-your-own culture, with the exception that C++ now has a decent filesystem module in the standard library but still no standard config file parser AFAIK, everyone usually imports nlohmann's JSON library.
Many of the programs complained about are written in C. I'm sure that there are libraries for c that abstract this, but there isn't one that is common enough that most c programs can depend on it.
XDG is a systemd standard that's not universally used across Linux distributions. It's most definitely not used in other UNIXy systems like FreeBSD and MacOS. XDG, like systemd, likes to believe it's universal but it's not.
> XDG, like systemd, likes to believe it's universal but it's not.
In XDG's favour, we can say that it is just a written convention that people are free to follow or not on a per-program and per-user basis. It is not a cancerous growth that tries to borg the whole system.
Practically universal. Even if there's a Linux distro going out of it's way not to set them, many tools, including big ones, support it anyway (also on non-Linux Unices). In practice I've never encountered users with a distro that didn't have these variables set.
I don't have XDG environment variables set in OpenWRT or ASUSWRT, the two Linux distros I run on personal equipment in my house. Also not set on my installs of FreeBSD.
XDG is a freedesktop standard that's been adopted by systemd, Wayland, and other important projects. It's absolutely no skin off your nose to adopt it, and beneficial to you and your users if you do.
What's late about it? It's out of date maybe, but as far as I can tell it's still alive. Did I miss an announcement?
I really like this one's approach. These guys created a kernel module to enforce their hierarchy and hide directories, etc. Such an interesting project!
Aren't dot files just pretending to be hidden due to a bug in early Unix?
Unix v1 had a flat filesystem. Unix v2 added subdirectories. As an implementation detail, each directory contained two magic files, `.` for "this directory" and `..` for "the parent directory".
The command to list files was sloppily coded to skip them. If a name started with a dot, it was skipped.
Hey presto! Unix 2 had a way to hide files! It was a bug, but it was useful, so it stayed.
So, Gobo doesn't use `/etc` and `/var` and all that 1970s nonsense, but it keeps them around, empty except for shortcuts, for sloppy code that assumes they are there.
But they are hidden, just like dot files are hidden on every Unix-like OS. Because it looks better, no other reason.
Fair enough, it's a mess mostly due to old conventions, the LSB, etc. I would be more satisfied with a kernel or init system or whatever that can configure where libraries are, temp data, cache, local software, system software, global configuration, etc. Then the primary difference in pathways for Gobo vs, say, Debian would be what paths they configured for Linux's main types of OS data.
It would make playing with alternative hierarchies kinda fun.
I think Nix and Guix have carried on similar concepts to Gobo in a much more elegant fashion (especially by not requiring the kernel to be patched...).
That's the standard build script setting the required compiler flags. Pretty mundane stuff, and nothing "inelegant" about it. It's not something Nix users or packagers need to even care about.
While the code is mundane and might not score any beauty points, it does offer a clear technical advantage. Namely, Nix doesn't require that packagers uniquely choose the installation path for each package. Instead, Nix guarantees that different package definitions result in a different installation path. This is one of the things that make Nix package definitions programmable because packagers don't have to manually resolve path conflicts.
Programmable package definitions mean more automation and customizability.
> Screw your conventions, we've always done it this way
I don't understand this section heading. To me, software convention has the third meaning as shown on merriam webster[1]:
> 3 d : an established technique, practice, or device (as in the theater)
In that case, that we've always done it that way establishes the technique, and the established technique is the convention.
To argue that non-desktop software should apply a desktop specification that they weren't involved in developing seems rather insane, especially since they are and have been following the established convention.
> To argue that non-desktop software should apply a desktop specification that they weren't involved in developing seems rather insane, especially since they are and have been following the established convention.
So what, stuff changes over time - and it's not that hard to migrate, either warn the user, or do the migration at first start. Good software should move with the times, not be perpetually frozen.
How many documents tell you to configure ssh with something in ~/.ssh/config and if the change is made, will now need to be changed to say put your config in one of many paths depending on the version you use?
What if you migrate your config and then roll back to an earlier version?
What if you use your home directory on multiple systems, some which have varying versions of the tool, loading the config from various places (network mounted home directories are a practice in some companies)?
What if you don't upgrade for ten years, and the migration code is gone by then?
What if you operate on a mix of systems of various ages, some which have the new path and some which have the old?
What if the migration code has a security vulnerability?
Personally, I don't see where the benefit is that pays for anywhere near any of this cost. Maybe if you're a desktop app that is within the scope of standards put out by the XDG, you might want to consider accepting this standard of theirs too; and sure, if you're a new application, seems like a might as well?
I thought about this, too. One fix would be for ssh to make a solid process that walks you through setting up your ssh config. Then it could be placed anywhere you like, and the preference would be set. Those docs would just reference the setup switch or tool, instead.
If you force me to migrate, I'm probably ditching your software. The inability to keep a stable user contract is a deep flaw that impacts too much software these days.
Everyone should do what emacs does (and a lot of software does): first look for .emacs for a config … not there? Check .emacs.d … still not there? .config/emacs …
That's not exactly what emacs does: if ~/.config/emacs isn't there, then it will default to creating ~/.emacs.d/ and ~/.emacs, even if the XDG env vars are set. Basically, emacs supports XDG config if you really want it to, but it's not the default way of using emacs. And of course, it only uses ~/.config/emacs, none of the other XDG folders. If you download a package from MELPA, that's still going to .config/emacs, as far as I know.
But also not without the downsides, because what do you do if multiple files are found? And how will you communicate that to the user, if at all? Lots of room for confusion here: "why aren't my changed taking effect?!", "where is this setting coming from, it's not in my file?!" and things like that.
Things like bashrc and vimrc have been "standard" for decades; that's not a "non-standard configuration", it's what everyone uses today. And Neovim only supports ~/.config/nvim/init.vim judging from the manpage(?) If it doesn't then this only underscores my point that all of this is apt to lead to confusion.
Either way, it had a clean break from Vim and didn't have to deal with people who have been using Neovim for decades (lots of things are different compared to Vim and it's not intended to be compatible in the first place).
It works for me. Established also has multiple meanings, but the most applicable one here says "generally accepted" [1]. Each listed piece of software has its own way of doing things, so speaking of _the_ established practice is wrong here, and I doubt I'd be able to list more than one of those off the top of my head, so _established_ hardly seems appropriate.
And whether you agree with it or not, I doubt anyone understands "desktop" as meaning "GUI only" and not "for human users" in this context. I usually see it used contrastively as in "desktop" vs "server". Server software lives in `/usr` and writes to `/run` and `/var`, etc.
> And whether you agree with it or not, I doubt anyone understands "desktop" as meaning "GUI only" and not "for human users" in this context.
Config files don't apply to only human users either, though. Automation also uses configs. And they've got to be somewhere. Some automation is desktop oriented, I'll acknowledge.
If this standard came from Posix, sure, that applies generally across unix and linux to all programs great and small. If it comes from Linux Standards Base, I've got issues, cause I don't run Linux, but that at least clearly applies to all programs on Linux, packaged by a distribution and configuration file locations are obviously within the scope of LSB.
But XDG is more or less the Xorg/Freedesktop peeps; how are config files for everything under the sun in their scope? There's lots of stuff in their scope, but this just seems out of the blue. Being not an exclusively Linux organization is somewhat helpful, but still. How is the XDG an authority on where to place config files when there was already a servicable location to put them (and the specification documentation doesn't even have a discussion of who they are, why their spec matters, how the values came to be, etc)
I addressed this in the article: Linux devs not being able to accept some authority—in this case, XDG—is the source of the fragmentation in Linux and why even though we have a spec, there's still a solid 30%+ of programs that don't follow it.
Yes, OpenSSH isn't a 'desktop' program, but there are dozens of desktop programs which use it as a backend. Forget Linux, for a moment: it creates `.ssh`on Windows. Windows doesn't have dot-files, and it never had. This is arrogance.
I'm curious about this angle. I think you're correct, that volunteer developers contributing their code from their free time are reticent to submit to an outside entity telling them how to write their code.
But I'm not seeing how that's a problem. One of the beautiful things about the Bazaar is that if you don't like one part of it, you can move to another where they do things a bit differently. If everyone is deferring to an authority, upon what virtues and rigors do we determine its validity? What powers does it have, and why should we just blindly follow others in one of the most creative human endeavors available on Earth?
Why should one accept authority? Where does the power of this authority come from?
I have similar ideas in society fwiw. I don't see a moral reason to defer to someone else. Is my will less important than the preferences of some other person or group? As long as it's my time and effort being put into making software, it'll be built to the specification of me and any legitimate stakeholders.
> I have similar ideas in society fwiw. I don't see a moral reason to defer to someone else
My opinions are probably a result of how and where I was raised.
That being said, I don't claim we should defer to authority for authority's sake. Authority is given by the people. In the case of the XDG Base Directories, for instance, I believe the specification is well-laid-out. It has gained enough traction and enough developers adhere to it that it has authority of its own accord: by accepting the specification, developers have voted to give XDG that authority.
Why should software development be a democratic process? It's not really democratic if one lacks a real voice in the conversation and formal votes are not held. The likelihood of a lone hacker being listened to by XDG or a similar group is similar to the odds of a small web firm being listened to by WHATWG.
The concept of authority as democracy doesn't really make sense to me. Does that mean you adopt any and all conventions once they hit 50.1%? I think we as humans can do better than just follow or limit ourselves to standards that may be popular, but are not necessarily the best tool for the job. I struggle to find many popular and mainstream software practices to be quality, or fitting for me despite the one-size-fits-all that such popular things try to aim for.
What is your role in this 'democracy', if you are actively lobbying for a minority (the XDG) to seize control over the way desktop software is written in the community, by way of writing the piece and it getting shared? That strikes me as manipulating a narrative to get people to "vote for" XDG. It's not a legitimate vote if you and others are actively evangelizing. It's called social pressure and canvassing.
Such social and organizational efforts are completely oblivious to the fact that they are operating in a bazaar, and their methods are designed better for Cathedrals. Cathedrals are used to tightly integrated stacks and top-down decision-making, so standards are hardly different than marching orders to the monks.
The bazaar is the wild west. The only authority in a bazaar is whoever owns the land. In a digital space, there is no land. So how does any authority -- controlling environment variables, of all things -- intend to exert itself in force?
If it's truly a democracy, then the voice of those who resist XDG is equally valuable and valid.
165 packages support XDG; 164 partially support it, where partial support really just means they have a way to configure the config path to an arbitrary file and if you tell it with an environment variable, it works; and 128 are unsupported. [1]
Based on that, if software is a democracy, the vote for XDG has failed, let's move back to dotfiles. Of course, moving config files is a lot of extra work and cost for users, so all the existing applications should get a pass for wherever their config files already are, but new application should follow the democratically elected choice of stuff dotfiles in the home directory.
Of course, I don't believe software is a democracy in the sense of voting and the will of the majority overriding the minority. Software is a democracy in the sense that the tools are open, so anyone can build what they want. Less restrictive source licenses allow you to take other people's work and build upon it how you want. Someone could fork all of the programs they use that don't follow the convention of their choice and "fix" them, and users could pick which one they like, software distributors could choose which one they'd like to distribute; etc.
From earlier:
> I addressed this in the article: Linux devs not being able to accept some authority—in this case, XDG—is the source of the fragmentation in Linux and why even though we have a spec, there's still a solid 30%+ of programs that don't follow it.
All authorities naturally have a scope. We don't all follow the style guides of the New York Times or the Chicago Manual of Style, although those are common to adopt in the United States because writing a style guide is hard and might as well pick one someone else did the work for. On the other hand, if you tell a UK person that they didn't follow a US style guide so they're arrogant, they'll quite rightly tell you you're arrogant and the standards of another country don't matter.
Sure, if you're writing new software, you should look around for the relevant specifications and consider picking one. If you're existing software, switching specifications is a breaking change, and you should consider what you get. You've said you find the XDG Base Directory Specification well-laid-out; but I find it lacking a declaration of objectives, justifications, and scope; those issues are non-starters for me, so I would chose the dotfile specification instead, unless I was writing something under the scope of the XDG.
[1] votes counted by separating out the tables, and grep -c '<tr>'; this is a poor way to run an election, but it's the data I have available, and the amount of effort I'm willing to expend
>Yes, OpenSSH isn't a 'desktop' program, but there are dozens of desktop programs which use it as a backend. Forget Linux, for a moment: it creates `.ssh`on Windows. Windows doesn't have dot-files, and it never had. This is arrogance.
I would say this is rather consistency accross OS.
Every openssh user knows where to find its config regardless of the OS, if it follows XDG, windows guidelines or if it is running on Haiku, SerenityOS, Redox or RiscOS.
There are plenty of windows specific ssh clients that follow Microsoft guidelines.
The multiple references to Microsoft being unable to follow their own design are shocking. If even the developers dogfooding can't find these conventions, how can they expect the peanut gallery to manage?
I don't use the XDG directories (I deleted most of them, and I created many of my own directories). However, sometimes I do override HOME for some programs in some circumstances; for example, I have made up a separate home directory for configuration files for pinball games so that I can use separate configuration for pinball games in the Game Boy (and Game Boy Advance) emulator. This would also be possible with other programs, even if they do use XDG.
An example: My own "Free Hero Mesh" software can be made to find its files in the same directory as the program file, but by default it is compiled to not do that if it is in your PATH. It will first look at the HEROMESH_PREFIX environment variable; if that is not set, then HOME will be used instead. (You can still override it with command-line switches, and by doing what I mentioned above. You can also configure it at compile time.) However, the only file it creates itself automatically is one that the other file (which you must manually create) can optionally override its path, so you should not need to worry about automatically created files in your home directory. (I do not currently target multiple operating systems. Others are free to try to port it if you want to do so (and I can answer any questions), but I do not expect to do it by myself.)
In fact, I too would want it; if I want a configuration file I should just create it by myself; this is how X resource manager is working and I think that is good. Unfortunately some programs insist to do it automatically themself anyways; in those cases I change the permissions of those files so that they are read-only so that the program doesn't automatically update the configuration file in this way (for example, this is the case with xdvi).
One, Red Hat is one of the major contributors to XDG, and is pulling developers away from XDG projects. To what extent I am not fully aware. We've learned time and time again that for-profit entities should not be in charge, or highly influential, in standards. They will inevitably steer them to favor their own ideas.
Two, what luck has the greater community had in getting their ideas adopted to the 'standards'? Standards are not meant to be inflicted; if a standard cannot gain enough consensus, and lacks authority to control who publishes software to a platform, then what good is it? XDG comes from the GNOME and KDE crowd, meaning Red Hat/IBM, Trolltech, and maybe Canonical or a few other token companies. Notice the complete lack of real community input or control? If I wanted to defer to a standards body, I wouldn't be interested in software. I don't think software is about bending to the will of some third party group's idea of how computing should be done.
Three, kind of a nitpick, but they adopted the Contributor Covenant CoC which is problematic for people who respect compartmentalization of social spheres. I don't care if there's a dipshit bigot on a dev team as long as he or she keeps it out of the work environment.
I have sidestepped the issue (in my mind) by putting all personal files in a `~/me` subdirectory, and create symlinks in `$HOME` to point to the relevant files in `$HOME/me`. It keeps things separate, and anything that's put inside an XDG folder that I want to hold onto can be migrated to ~/me and symlinked. I keep a short bash script that I use to (re)create the symlinks for me, as needed.
A distro that feels really strongly about XDG could patch, or refuse to package anything that doesn't adhere to XDG. I wonder how far that approach would go.
In short, I am just not impressed with the way XDG is handled, nor the literature that gets pushy about people adopting it. The author used a sleight of hand to imply that XDG is an authoritative standard or that it has universal consensus. It is not, and does not. This dishonest representation of the XDG standards are part of why I am turned off by them. It's the same social approach that PulseAudio and systemd used.
If things are good, they will be adopted on their own without any advocacy needed.
(Edit: added third concern after checking their site more)
> XDG comes from the GNOME and KDE crowd, meaning Red Hat/IBM, Trolltech, and maybe Canonical or a few other token companies. Notice the complete lack of real community input or control?
You're completely erasing the community involvement in KDE and GNOME. Moreover, it's grassroots that push utilities to follow the basedir-spec.
> Three, kind of a nitpick, but they adopted the Contributor Covenant CoC which is problematic for people who respect compartmentalization of social spheres. I don't care if there's a dipshit bigot on a dev team as long as he or she keeps it out of the work environment.
Again a misrepresentation. The CoC says to be tolerant of all contributors, and not doxx folks. Hardly burdensome. These are rules which nobody would ban an eyelid in a professional context.
> You're completely erasing the community involvement in KDE and GNOME. Moreover, it's grassroots that push utilities to follow the basedir-spec.
What community involvement in KDE and GNOME? The GNOME guys tend to be dismissive of anything not fitting into their grand vision. I'm not sure what distinction you're trying to make on the grassroots comment. If a project has a majority of paid devs on it, it's de facto controlled by a company. The users don't really have a choice or an influence in those two projects.
They also don't have a choice if a bunch of people come together to force their idea of proper standards on the greater ecosystem. It's simply toxic social behavior.
> Again a misrepresentation. The CoC says to be tolerant of all contributors, and not doxx folks. Hardly burdensome. These are rules which nobody would ban an eyelid in a professional context.
Firstly, not a misrepresentation:
> This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community.
Look at that little wiggle room -- when you're representing the project. When does that apply? Who decides that? What's stopping FD.o and other CC CoC consumers from declaring that all contributors represent the project at all times?
This precise verbiage has been used to cause ruckus and harass people, because there are different customs and expectations between contributors as to where the line is on when you are representing the project.
Morally speaking, a project has little justification for punishing or ousting a contributor for any conduct that occurs outside of its infrastructure or community.
I don't care what the professional context is. That's another word and concept that means different things to different people, and is better used as a bat to shame people with than to form any reasonable standards of behavior that respect personal liberties and variety of expression. "Professional" people care far more about appearances and prefer to deliver their poison in etiquette-approved containers.
How often does one see behavior or words labeled as "unprofessional", without any logical or rhetorical backing? Personally, I see it every time it's accused.
I'm interested in reading about any community-driven features or standards that XDG has collaborated with the community on in good faith. i.e. something that was added without the need for a company to sponsor or approve it.
I think both are worthy of criticism. No project out there is able to separate technical and social concerns, any more than you can separate the logical and emotional parts of a person. Every project has social and technical standards. It's the pure focusing on one or another that skews peoples values on making software.
I am against the solution because it requires yet more environment variables that need setting if you don't want a bunch of Windows-looking folders in your $HOME.
There are a great many things 'well-intentioned' in this world. I'm simply less convinced and more aloof to efforts that steer the way we compute.
The article and discussion have already shown that even proponents or adherants to XDG can't decide where things go. Data and cache get used interchangeably, and if I or a group of hackers want to improve or influence the standard, we will be stopped by the big desktop makers.
Usually, adopting standards comes with great benefits for everyone. The big guns win control if we capitulate to their way of building software.
I honestly see little reason we can't have competing 'standards' on file paths. That practice would encourage software to simply make its config path changeable at runtime.
There are too many people trying to turn GNU/Linux into one monolithic thing that's the same for everyone, and that defeats the moral point of free software. If I was required to follow these standards to get my software into a distro, I'd have moved on a long time ago.
The 'problem' with freedom is it lets you keep the pieces if things break. What you do with the pieces -- lean to XDG, switch OSes, make your own hierarchy -- is up to you.
Maybe the culture and community needs to be forked. There's clearly a group of hackers that loves bureaucracy and consensus before code is written, and another that doesn't really care for either of those things.
If others choose to look solely at the technical, then they will be led on like fools by the socially-targeting people, who aren't just looking to solve technical problems.
So what was the point of claiming I have no problem with the solution when I've not communicated that?
Wrt point 3, it's how one is supposed to act while in a group. You don't know them outside of the group, and it's none of your business what they do outside of the group. Some may claim that's overly tolerant, but in my opinion if a bigot behaves while working, it shows they know their ideas are unpopular and they have the tact and decorum to not bring it up. How they act outside the group is not up to the group.
Indeed that is part of the concern. Lennart was an influential person while at Red Hat. When you see the same few people coalescing around 'standards' forming and everything they peddle happens to involve them or be written by them...
The guy works at Microsoft now. That ought to tell you where his values were for free software this whole time.
> I have sidestepped the issue (in my mind) by putting all personal files in a `~/me` subdirectory, and create symlinks in `$HOME` to point to the relevant files in `$HOME/me`. It keeps things separate, and anything that's put inside an XDG folder that I want to hold onto can be migrated to ~/me and symlinked. I keep a short bash script that I use to (re)create the symlinks for me, as needed.
You or interested readers could use GNU stow to do that.
It's interesting, Stow is great if you're symlinking single locations to many symlinks, or merging directories, but I had a hard time generating stand-alone, relative symlinks in $HOME with stow that didn't also mess with things in other ways.
I use Stow myself to source music files from multiple root directories, it's a great piece of software that I simply could not wrangle to pull off what I was after.
Thanks for mentioning Stow, though; it doesn't get enough love and if you're smart with it, you can do some crazy things that, manually, would take hours or days.
One "solution" to this problem in Linux is to use something like bwrap[0] and manually redirect offending software to the desired location with the "bind" option.
You probably can't get the individual directories for different purposes (.cache/.config/.local) because offending apps are unlikely to have these concepts (otherwise they probably wouldn't be offenders to begin with...) but you can just slam everything from $HOME/.foo into e.g. $XDG_CONFIG_HOME/foo and go.
This is great! Also super helpful to me as someone with way more experience in one OS than the others. I will definitely be referring to this in the future.
Yes, if you are writing new software please respect $XDG. But its a bit ridiculous to think that bash should respect some convention developed ~20 years after bash was released.
There are countless tools that write to the bash files though, which is not true for most programs. Bash changing its locations would break all of these.
Heck, git adopted ~/.config/git years ago, and yet just last week I ran across a tool that created and wrote to ~/.gitconfig instead of my ~/.config/git/config. If Bash tried to change then we'd be dealing with the fallout probably forever.
>There are countless tools that write to the bash files though
Which is terrible, btw. Configuration using untyped, unchecked files, readable & writeable by almost everything is one of the worst parts of Linux. Especially when it exists in a directory the user should expect to be their exclusive domain.
I agree with you there. I don't remember which it was, but one of the runtimes managers (was it pyenv, rvm or nvm?) wrote to my .bashrc and .zshrc without asking for permission to do so, instead of just telling me the locations it wants me to include in my $PATH. I don't do path munging in my zshrc, rather, I source a different file that I use to manage this stuff and set up a way to avoid duplicates in $PATH and only adding things to $PATH when they exist so that my shell configuration doesn't do anything dumb when used across multiple computers.
Well, I'd rather their attempt at writing to my shell config breaks.
This is one of the many reasons why you should, if you haven't yet, manage your dotfiles with version control. Many tools assist in giving you some sugar over the process, I use homeshick which will move files away into a git controlled folder and create symlinks.
It's not that "terrible" in the first place, all things considering, and breaking people's workflow just to satisfy your preferences is just anti-user and a good way to piss off people.
The correct way to handle this, for any projects forcing the change, is to use a staged deprecation period:
* first, you add support for XDG
* second, wait at least one version to give people time to get used to it
* third, switch the config location search order so it checks XDG before .whatever
* lastly, after an announcement and deprecation period, and at least 2-3 releases, remove support for the .whatever folder.
(To be fair, it's totally possible that my upgrade path with ncmpcpp skipped over some steps and they actually did it correctly. Will have to check when I care enough to dig through commits.)
If it is that terrible, I guess the good way to do it is not to break stuff to people using bash, but to use another shell, possibly a fork that will be expressly known to not use bash original config files.
That way you can introduce the new guidelines while not breaking stuff to those who want the old bash.
There are multiple reasons why tools shouldn't be doing this.
First, I don't like tools overwriting my configuration. My dotfiles belong to me and I have things configured the way they are for a reason. Tools should inform me if changes are required to my configuration, and not just go and change it by itself.
Second, it prevents users from making their configuration files read only. This affects users of Home Manager by the way, which deploys configuration files as symlinks to read only files under /nix/store.
Even more egregious are files that write mutable state to configuration files, which makes them unsuitable for version control. Unfortunately, Docker is guilty of this and stores mutable state in config.json.
Finally, as mentioned, it interferes with XDG adoption.
Personally, I'm all for breaking tools that write to user configuration files. They cause too many headaches with no clear benefit.
Wouldn't the tools which write to (and presumably read from) the Bash files break if the user were to do something like use another shell? While Bash has its niceties, I really can't go back to not being able to autocomplete "~/pr/l/Ka/RE" to "~/projects/lisp/Kandria/README.mess" with a single TAB.
I've never seen .emacs anywhere other than $HOME/.emacs, or seen Emacs write files outside $HOME/.emacs.d. In what situation does Emacs use $HOME/.config/?
Since Emacs 27.1, if $XDG_CONFIG_HOME/emacs/ exists and neither ~/.emacs nor ~/.emacs.d/ exist, then it will set user-emacs-directory to $XDG_CONFIG_HOME/emacs/ instead of ~/.emacs.d/.
So, if I understand correctly (and this would match my experience), if I compile emacs from sources on a new computer and just run make install, the "legacy" paths will be used instead of the XDG ones, unless I explicitly mkdir $XDG_CONFIG_HOME/emacs.
I would then say emacs supports XDG, but doesn't use it by default, right?
Based on the other comments, it sounds more like emacs supports XDG if you want it to, but still defaults to ~/.emacs if you don't explicitly set up an XDG environment for it. Distributions may choose to do so, but I don't think compiling from source does.
When you create $XDG_CONFIG_HOME/emacs/init.el before starting emacs for the first time your `user-emacs-directory' will be set to it. However, the other locations (.emacs, .emacs.d) are always preferred if they exist.
Refer to section 50.4.4 (How Emacs Finds Your Init File) of the manual for more information.
Pretty much everything I do on a daily basis is in ~/something, immediately in my home directory. It used to be ~/Projects/something but even that felt too organized.
My home directory also accumulates an ungodly amount of shite over the course of mere months. I refuse to use /tmp — what if I need this again at some point in the future?
x.txt that gets shared in chat, PATCH_broken? for an idea given to me that I couldn’t apply to master, image0001.jpeg and friends showing screenshots I dumped into code review and forgot to delete, notes816_review.md thrown together in haste in a meeting, xx.txt, AAA, AAAA, AAAAAA, v.sh, vrewrite.py, etc etc.
Every few months something creeps in with a massive filename and breaks ls’s tidy columnar output. At that point I bundle everything up into a directory called ~/Projects/Scrap/2023-08-16.
Over time you end up with these lovey scrapbooks of mostly crap but occasional gems like screenshots of growth stats graphs from 2008 or a PDF of Leuchturm’s product catalogue in 2011 or an example.c that helped solve an obscure bug or a list of yays/nays for a house party.
I am a hoarder of the worst kind. Real digital hoarders at least have racks of drives to keep their house warm. This stuff is barely 400MB.
Aha, I repurposed the XDG download directory to point to ~/scratch/, since most of those files are downloaded in my browser. Now I dump everything into that directory that hasn't been sorted into my hierarchy system (which is divided into ownership or source, then type or relevancy).
Having strewn files about is so stressful for me, I have to squirrel it away in one place or it will drive me batty. I'd rather have one directory holding all of that crap, so if I ever have a "screw it" day, I can `rm -rf ~/scratch/*` and be done with it.
Have you tried to sit down and create a hierarchy that makes sense for your way of thinking? I spent a weekend working on it a year or two ago and it's made things SO much better. I won't suggest any particular structure, but here's a rundown of what I put together: https://imgur.com/a/QVehjvy
I love reading about people's directory or symlink structures.
Can confirm, as a digital hoarder with a medium size PC case with 8 16-20TB drives...No need for turning on the heat in the winter. Summer is a bit of an issue though!
That's close-ish to what I do, which is to have symlinks for frequently used directories in my home directory. And as most of those directories are actually on an NFS server, setting up a new PC is just mount the server, create the symlinks and then "cd someproject" or "cd ~/someproject' as usual (well, as long as you make sure you use the same UID/GID anyway).
For games, I think it's even worse on GNU/Linux systems, since most game developers mainly target Windows and sometimes completely ignore conventions for other platforms (possibly since some game engines have that "Build for Linux" button).
This also applies to game engines and their own conventions. For example Unity has Application::persistentDataPath[1], which uses $XDG_CONFIG_HOME (still a bit meh, since I wouldn't treat savefiles as "config", but at least some convention). However, some games tend to write those into Application::dataPath[1] (or even other random directories they see fit), which is supposed to be read-only and could possibly be outside of $HOME.
Fortunately the single one advantage of antivirus software out there seems to be that the above seems to break with some AV, so developers either tell their players to disable AV or they simply fix the issue. I made countless bug reports on this issue and so far it exclusively got fixed because of AV, so I'm using that as an argument for future reports.
While at least most of the Unity games I've packaged seem to adhere to these conventions, other games and game engines are a mixed bag and I've seen games dumping their stuff into $PWD to games writing to Windows paths (eg. /home/foo/SomeVendor\Somegame).
Patching these games is also very tedious, since some of them tend to get updates, so patching needs to be done in a way to be forward-compatible.
For example here is a patcher I wrote to get Factorio to adhere to XDG:
And not a very controversial one among this crowd.
I'll second it, too! I've never seen an interesting argument in favor of macOS' app-centric model of task switching or stupid 'zoom' behavior, and have only discovered two features that I like in that whole system (menu bar searching and rebinding menu bar hotkeys).
Seeing as I cannot control all the software I have on my computers, I just gave up.
Everything in $HOME that I care about is in ~/my. $HOME itself is anarchic, and that's okay with me. I have better things to do than micromanage this.
Most infuriating when you run VS Code in "portable" mode and it creates at least 3 directories in $HOME. Sadly, the only solution is to use Flatpak and prevent application access to $HOME, by redirecting to alternate locations.
ATMO the XDG standard is broken by design, and has been designed by drunk people who wanted to emulate the bad behaviors of windows users.
Why would we want cache file in our home directory when we have a /var directory for this kind of stuff and especially a /var/tmp directory which has the sticky bit ? Who decided that cramming stuff into ~/.cache was a good idea instead of putting it in /var/tmp/usercache-<username> directory?
Why would we want a .config and .local directories full of binaries, artifacts and config files within our documents when we have /usr/local for that? Put that into /usr/local/<username> instead!
And then comes the terrible folder list:
Desktop : this one is largely unused by me, why putting icons in a screen when they will be mostly obscured by windows while I am using my computer? Do we have to replicate all bad ideas of Windows?
Documents : this one is okayish, but why isn't my whole homedir a documents homedir if we can clean it up from all the config, binaries and cache shit eh? Aren't Pictures, Music, Videos or what I download documents too?
Downloads : that one may be useful, although /tmp would be more interesting to me. For the most part if I don't use the files I download immediately I will never look for them or they will be possibly obsolete by the time I find them. It forces me to do housekeeping while having them in /tmp would clean the shit at next reboot.
Music: ok I suppose but nowadays lots of people are using streaming, I mean I can create it myself if I want to.
Pictures: this one is stupid, why is a picture not a 'document' and why would we need to separate it? What do I do if I want to put pictures asset in my markdown document? Should I point it to some obscure directory here or should I put it in myproject/assets/ ? OK some would argue this is a good place to auto import your photos from your camera but wait. If one day I use digikam but then I later decide it is not so great and want to use something else it is likely to make a mess.
Public: most people never use that. It is for file sharing purpose I reckon but it can be created whenever you need to by the 0.2% of people who will use it.
Templates: same as public, people are never that organized and will rarely put templates there instead of next to their docs. I never saw any app making use of that, most of the builtin templates are provided with the package and are stored in /usr/local
Videos: same stupidity as Pictures. My Videos ARE documents. Besides, what if I want to keep the videos of one event or my vacations next to the Photos? Why would I want videos of my kids playing on the beach be next to regular movies, porn, videos from a sports event I participated at or screen recordings?
All these folders are meant to target a majority of users but in the end create a fake sense of organization that doesn't really work for anyone, everybody end up having files everywhere and/or only partially following those conventions which end up with the same mess as having just the regular mess /home/<username> or /usr/local/home/<username>
I think I'm in a similar boat, great criticism of the user dirs. The directory structure seems too wishy-washy. Users can tweak where the actual directories are, and there are descriptions for what each env-var or directory should have, but the divisions made between types of file are not semantic enough, imo. And, agreed wrt temp files or cache files. There's /var/tmp or /tmp already, /usr/local/tmp, /usr/local, and so on. Permissions 'being weird' on most distros is something that can be addressed or fixed; no different than pushing people to change to XDG. In fact, it might be more beneficial to more projects if we get better-standardized "scratch space"s.
But then we'd be running into another cobbled together standard, with an even uglier history: The Linux Standard Base hierarchy. Which I just learned died a few years back. Huh. Turns out the filesystem is not something easily wrangled... System paths are something I've thought would benefit more from being configurable with env-vars (maybe even in the kernel argument list on boot, or via grub?). The major differences between distro filesystems would be abstracted away to their boot settings.
/boot/grub/linux-dirs.conf when?
I see some benefit in abstracting utility directories behind an interface so application developers don't have to worry about it, but the way it's gone about seems backwards and highly dependent on your environment containing the right variables. It probably needs to be handled below the user/application layer.
That would definitely be the way to go, sadly I think the linux desktop has to much inertia and it can only solved in a different OS, called a different way with its own directory structure. Where package maintainers are instructed to not package or patch any app that do not follow sane standards, where a flatpak equivalent would not put stuff into the same directory as the user's files, where a rootless container or a vm hypervisor would not put its stuff in the same directory tree
While it is not dead, Gobolinux failed probably because it was still advertised as linux, so people expect linux to follow some standards. I have no idea how redox, haiku and serenityos are handling that stuff, I hope they have been smarter.
Serenity is basically the same. Haiku is too close for comfort, but it's simpler because it's essentially single-user at present.
You want a radical idea? May I try to explode your brain?
We have persistent memory now. You can put a few terabytes of nonvolatile storage in your DIMM slots, and it's cheaper than RAM.
If your computer's memory map is entirely directly-addressible storage, every byte of every file is right there in the address space, all the time...
Then you don't need indirectly-addressed storage any more. No drives of any kind. No files of any kind. It's all in RAM all the time. You can dispense with filesystems completely and just manage it via an in-memory database or something.
No more folders. No more 2-dimensional tree. Every block of data can be found in 26 different indices if you want. Individual blocks of data can be in multiple programs, or documents, at once.
All that '70s hard disk stuff can just go away now.
But we're too scared. All we know how to do are disk drives and files in folders.
I am intrigued by this. I have an SSD that I cannot use due to the lack of an M2 slot in my desktop. How is this accomplished? Do you need an adapter for M.2 to DIMM?
Memory corruption could be more disastrous due to its persistence, but given the RAM bus is faster than SATA... This might work!
Thanks a lot (belatedly..) for the links! I have something new to consider in my next build. I really like this idea, it allows for a ton of freedom and you could do some weird wizardry with it. Also a lot of data corruption, haha.
I also don't really like XDG so much. I don't use any of those Desktop, Documents, etc; in fact I deleted all of them. I also do not use a desktop environment either. I use Linux, not Windows. (For documents, downloads, etc, I would specify explicitly each time what directory and file names I want, since they are often different each time anyways.)
> instead of putting it in /var/tmp/usercache-<username> directory?
Can't use fixed paths in tmp dirs, that's either a security issue or a denial of service attack waiting to happen. I can `mkdir /var/tmp/usercache-prmoustache`.
> Put that into /usr/local/<username> instead!
Not writable to regular users, and not meant for that.
> Can't use fixed paths in tmp dirs, that's either a security issue or a denial of service attack waiting to happen. I can `mkdir /var/tmp/usercache-prmoustache`.
Well we don't even need a fixed dir, a session generated dir with an env variable set to it is enough.
Or we could put that somewhere else in var. We created /var/run/<users> dirs, there is no reason we couldn't do other directories for other uses.
>> Put that into /usr/local/<username> instead!
>
>Not writable to regular users,
fixable
> and not meant for that.
I am pretty sure I have used some BSD in the past where the home directories were in /usr/home and /usr/local is a pretty good spot to put what is -- wait for it -- local to the machine!
There is no reason we couldn't have all our user owned binaries in /usr/local/<username>/bin and /usr/local/<username>/lib and our configs in /usr/local/<username>/etc
It would just have to be created at user creation with correct user rights but that is no big deal.
Users would just put their files in their /home, be able to sync it accross machines/ possibly different OSes without necessarily synchronising config files that do not apply to it or worse, unneeded cache files.
Their /usr/local/<username>/etc could be a git (or other versionning system) repo
Their /usr/local/<username>/bin lib share whatever could be saved and restored easily
And all the variable/ephemeral shit/cache could go to var where they belong.
What I also know however, is that creating a custom template is not something most users have been waiting for not something they use expect maybe for a tiny fraction that looked for that possibility and read the corresponding doc.
And that tiny fraction of power user could have created that directory when needed while currently it is just an empty dir that sits unusead on probably 99% of the users homedirs.
When the large majority of developers converges and compromises to reach an agreed-upon standard, it is arrogance to continue to stake it out by oneself, however old said existing project might be.
Real-world equivalent: the imperial system of units dates to ancient Rome or older. The English used it throughout their empire. On the other hand, the SI units in their most modern form are barely a century old, and yet 95% of the Earth's population lives in a fully metricated country. Most metrication efforts happened in the last 50 – 70 years.
I think the XDG standards are largely good and I wish everyone would adopt them, but it was absolutely not the result of "a large majority of developers" reaching a standard. It was a very small minority.
> When the large majority of developers converges and compromises to reach an agreed-upon standard, it is arrogance to continue to stake it out by oneself, however old said existing project might be.
Didn't the large majority of developers converge and compromise to stuff dotfiles into my home directory directly? I've got 41 dotfiles in ~, one of which is from the software project known as config, which apparently has settings for glib-2.0?
Look up how XDG_RUNTIME_DIR gets set. Its a pam_systemd(8) thing and thus specific to GNU/Linux. So if you approach the non-glibc or *BSD folks with "please follow the XDG spec", you will likely not receive a nice answer.
1. $XDG_CONFIG_HOME/.op (if var is set) 2. $HOME/.config/op 3. $HOME/.op
I hate to be the dev who says “I don’t know why those other code bases find it so difficult that they put up a fight” but our `findConfigDirectory()` function isn’t exactly complicated, even when you consider all the operating systems that the 1Password CLI supports.
(Sorry for the formatting, I’m on my phone.)