- cross-posted to:
- programming@lemmy.ml
- cross-posted to:
- programming@lemmy.ml
Shameless plug: I am the author.
You must log in or register to comment.
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.
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_HOMEwhich 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.
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:
- .android: hardcoded in adb and i guess something in mtp too
- .pki: some tool/library Firefox and Chromium sometimes use.
- .steam: yes, that
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
$ZDOTDIRin/etc/zsh/zshenvand 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
.localdirectory back then, it was 1 week ago that I changed.localforLocaland that let to an issue with distrobox which I made a PR fixing it that’s still open though.That’s awesome!
This is probably a dumb question, but what program is that?
Looks like thunar (default file manager on xfce)
thunar (and the smaller window is the xfce4-terminal).
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.
It’s not too hard to check for XDG support first and use a few hardcoded directory paths if that is unavailable.
It’s even easier to ignore it altogether, which is what I do. I don’t use “a few” non-XDG-aware things; I use lots an lots of them.
Are you saying that you don’t want to write your software according to the XDG spec, or that you don’t want to set the XDG env vars on your system? If it’s the second that’s fine - apps using XDG work just fine if you ignore it. If it’s the first I’d suggest reconsidering because XDG can make things much easier for users of your software who have system setups or preferences that are different from yours; and using XDG doesn’t cause problems for users who ignore it.
OP’s recommendation is aimed mostly at software authors.
I meant the second. But as to the first: I generally write in-house software for headless server environments, and my peers are going to push back if I add irrelevant XDG foo to my PR.
My fellow FOSS users, patches are welcome.
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.
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’s less clutter, especially if you’re browsing your system from terminal
- it’s a single, specified place for user specific configs, session cache, application assets, etc. Why wouldn’t such important foundational things required for running apps not be in a well defined specification? Why just dump it gracelessly in the user’s root folder outside of pure sloppy laziness?
- it makes uninstalling apps easier
- it makes maintenance easier
- it makes installing on new machines easier
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?
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.
This is true, and something that I’m working on. For some reason my brain is uncharitable in these situations and I interpret it not as a simple question but a sarcastically hostile put down in the form of a question. In this case, “Why would you be dumb and not just put things in /home”. That really is a silly interpretation of the OP question, so I apologize.
As to using this standard, just because this is your preferred standard, doesnt mean its the only standard.
Sure, but the OP was essentially asking “Why isn’t dumping everything into a user’s /home the standard? Why are you advocating for something different?”
Based on their own description, they aren’t even an official standard, just one in “very active” use.
There are a LOT of “unofficial standards” that are very impactful. System D can be considered among those. The page you link to does talk about a lot of specifications, but it also says that a lot of them are already under the XDG specification or the reason for XDG is to bring such a scheme under a single specification, i.e. XDG.
So why this, specifically? Just because its what you’re already doing?
- yes I do use it, so I am definitely biased in that regard
- it bring a bunch of disparate mostly abandoned specification into a single, active one
- it’s the active specification that has learned from past attempts
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.
Oh so it makes it impossible to change config path? Yea that’s a bit inconvenient but you always can just make many files and replace the file in the right directory with the one you want.
Not if you want to use both at the same time. Due example, I’ve wanted to have a local Gnome session that I leave signed in, and another session with different settings that I remote into.
there’s no place like 127.0.0.1
there’s no place like XDG_CONFIG_HOME.
BRB, putting in a PR to make /etc mode 1777 by default.
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.
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
حق
Are there abstractions available around the XDG specifications to resolve the proper paths?
What language? Python has PyXDG.
In shell it’s simply
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.
Depends on the programming language. In C# for example, there’s an API to get special folder paths that works in all supported environments (Windows, Linux, MacOS, Android, and I think iOS too). On Linux, it includes fallbacks in case the environment variables aren’t set.
yes please!
