My fellow software engineer, It's the year 2024...
Attached: 1 image My fellow software engineer, It's the year 2024. Please store your #Linux #desktop application configurations ONLY in `$XDG_CONFIG_HOME`. NOT in `$HOME` or other non-standard or obsolete places. May #FreeDesktop be your guide. https://www.freedesktop.org/wiki/Specifications/...
Shameless plug: I am the author.
Golang puts shit specifically in $HOME/go. Not even .go. Just plain go.
Why is it so difficult to follow industry standards
Go pisses me off with that. I separate projects the way I want but go wants every project written in go in one big directory?
following industry standards
pick one
This post literally links to the leading one.
off the shelf go was too annoying for me
Nowadays I set GOENV_ROOT to an XDG location and use goenv instead.
Shout out to xdg-ninja - it'll find files that are in your home and suggest how to configure the app to use XDG instead. https://github.com/b3nj5m1n/xdg-ninja
Strange that some apps allow configuring it rather than just doing it automatically...
That's the usual open source way. The config probably came later so they just added the option without changing the default because that would break backward compatibility.
And there would be too much boring work to build a migration.
Thanks, I hadn't heard of that. Time to add a few hundred lines to my dotfiles :)
After running it and properly configure the paths I once again came to the conclusion: I fucking hate Google.
I wish they used them all, especially XDG_CACHE_HOME which can become pretty big pretty fast.
And i wish there was a separate XDG_LOG_HOME or $HOME/.local/log, with logrotate preconfigured to look there.
Or $HOME/.var/log.
100% agree and I also despise devs who do this on windows, instead of using %appdata% they’re using c:\users\username.myappisimportantandtotallydeservesthisdir
I have to use a separate Documents folder for my actual documents lol
I think that also causes issues for roaming profiles and folder redirection. If roaming is turned on then everything in the %appdata%\roaming folder is synced to a server. %AppData%\Local is not. So if your app is using %AppData%\Roaming for temporary data then you are causing a whole bunch on unnecessary IO. Same for using Documents since that if often synced.
Not to mention - this isn't necessarily the correct place for Windows anyway. That is exactly why they standardized stuff around Vista.
Plus - what about apps that store an ungodly amount data in there? Personally, I only keep the OS and basic app data (such as configs and cache) on the partition and nothing else.
Then something like Minecraft comes along and it's like "humpty dumpty I'm crapping a lumpty" and stores all its data in ".minecraft" right there in your user directory.
Then you gotta symlink stuff around and it becomes a mess...
To be fair here, appdata is technically a hidden folder and there are lots of reasons an app would want it's data accessable by the user.
Yes but then just spam the documents folder like anyone else, don’t hoard the home root for no reason except that is a lazy cross platform port
I didn't know about this (and thankfully, haven't written anything public). I've been trying to fix an install script for an OSS project that doesn't work on immutable distros, and using the XDG Base Directory specs might just be the panacea I was looking for!
Where did i read this... basically, the .file being hidden being a bug in the early unix filesystem, which got misused to hide configuration files.
Offenders despite XDG-variables set and with no workaround:
Shameless flex
I regret checking this
Whoa I’m a stickler for getting as much as I can out but even I have .zshenv and some other too hard to figure out things in there. How’d you manage a total wipeout?
zsh is actually easy and it is detailed in the archwiki
You have to set $ZDOTDIR in /etc/zsh/zshenv and iirc that was the only location that required root to edit.
For the rest of stuff, here is how I fix steam for example and you can check the rest of my dotfiles for how I configured zsh and all of that.
Although I haven't updated them, I still had a .local directory back then, it was 1 week ago that I changed .local for Local and that let to an issue with distrobox which I made a PR fixing it that's still open though.
ls Volatile
Here is a more concise way to achieve the same thing:
bash
ls -ACd ~/.??*/ | sed -e "s#$HOME/##g"
I think that can be boiled down to only cd; echo .*/
Maybe throw a ;cd - on the end if the change of directory is unwanted.
if you need to preserve cd - you might be able to do this with pushd and popd
ls -A | grep "^\."
I had to make a dummy .dotfile to test because I don't have hidden files in my home.
My fellow FOSS users, patches are welcome.
there's no place like 127.0.0.1
there's no place like XDG_CONFIG_HOME.
vim now has an option to put the .vim folder in ~/.config; though I'm not sure if the default plugin/package & syntax folders can be set under ~/.local/share.
You can also just use neovim instead, among other improvements, it's configs are in the xdg dirs
BRB, putting in a PR to make /etc mode 1777 by default.
YOU'RE NOT MY MOM I'LL DO WHAT I WANT
yes please!
Are there abstractions available around the XDG specifications to resolve the proper paths?
What language? Python has PyXDG.
In shell it's simply
undefined
XDG_DATA_HOME="${XDG_DATA_HOME:-"$HOME"/.local/share}"
XDG_CONFIG_HOME="${XDG_CONFIG_HOME:-"$HOME"/.config}"
etc.
Thanks, I did not know about PyXDG. That was the type of thing I was asking about.
Use the environment variables.
I do. But you might have misunderstood my question. I was not asking for assistance. I was just curious if there are libraries available which allow easy adoption of the XDG specification. I imagine that such abstractions would be useful for multi-platform software and generally to lower the bar for adoption.
حق
Probably half the entries in that list are not GUI apps, and XDG doesn't apply (though some still support it). For some others there (like emacs) XDG is used if it exists.
XDG doesn't apply for CLI apps? About half of dirs I still have cluttering my home are GUI apps whose devs refuse to follow the specification, while I see less friction from CLI/TUI devs, since they're the ones actually seeing these hidden locations.
What makes you think XDG doesn't apply to non GUI apps?
It's already in the name - XDG stands for X Desktop Group (nowadays freedesktop), which works on interoperability for desktop environments. In a pure shell environment (or even if you're not running a full desktop) none of the XDG variables are defined, and especially in shell environments the default fallbacks specified by XDG are not necessarily what the operator would expect.
This would just further complicate things for me. It assumes that 1) the system even has a windowing system/desktop environment or 2) all the installed software is XDG-aware. Most of the time I’m fiddling with headless environments.
So yes, "XDG" stands for "Cross-Desktop Group" - but I don't agree that using the spec assumes a windowing system. The base directory spec involves checking for certain environment variables for guidance on where to put files, and falling back to certain defaults if those variables are not set. It works fine on headless systems, and on systems that are not XDG-aware (I suppose that means systems that don't set the relevant env vars).
OTOH as another commenter pointed out the base directory spec can make software work when it otherwise wouldn't on a system that doesn't have a typical home directory layout or permissions.
The spec doesn't make those assumptions at all, idk where that's coming from.
Whatever happened to Linux being all about choice? Do you want that or not?
You can choose any home directory you want, as long as it's XDG_CONFIG_HOME.
Choice, huh? I can't choose where the config files are stored unless I am willing to either dig into an obscure setting, modify the source code and recompile (repeat every time there's an update), or contact the developer's smug beard using smoke signals.
idk that all sounds like choices to me
But what's the difference? It'll be in /home anyways and I heard BSD had some issues with something that could be XDG.
For me personally I just hate that I do not know where to find configs, especially when using a dotfiles repo, it becomes harder than if they're all available under a common path.
Better organization and backup / restore. For example if you want to restore config files but don't want to move over the large ".local" folder, applications that write to $HOME will create diifculty.
Because, like /etc, you know there is a designated place for config files. It's already set for you right there, and there is a standard for it.
/etc is a standard, defined in the filesystem hierarchy standard. This is not:
freedesktop.org produces specifications for interoperability, but we are not an official standards body. There is no requirement for projects to implement all of these specifications, nor certification.
Below are some of the specifications we have produced, many under the banner of 'XDG', which stands for the Cross-Desktop Group.
Its nit-picking, but this is a specification, i.e a preference, not an official standard. It would be great if everyone would agree on just one of these to use, but that isn't a foregone conclusion. Even the actual standard, the FHS, isn't followed by popular OS's like NixOS.
But what’s the difference?
I can only imagine someone asking this if they a) don't use the terminal except if Stackexchange says they should and b) have yet to try and cleanup a system that's acquired cruft over a few years. If you don't care about it, then let me flip that around and ask why you care if people use XDG? The people who care about it are the people in the spaces that concern it.
Off the top of my head this matters because:
It’ll be in /home anyways and I heard BSD had some issues with something that could be XDG.
🙄
Someone asking a question doesnt merit the insult of saying they "would never ask if they used a terminal." I have no particular dog in this fight, but not being a dick isn't that hard.
It may actually be the best now, but so were the 14 others that came before it. Your stated reasons are the same reasons as everyone agreeing to use any other standard. Consistency, predictability, automation,ease of backup/restore, etc.
What sets this standard apart from all the rest? Based on their own description, they aren't even an official standard, just one in "very active" use.
So why this, specifically? Just because its what you're already doing?
To give one example, what if someone wants to have more than one set of options for the same app? That's something I've needed before, and it's really hard to accomplish if the app always looks in one specific place for its options.
