[OJFord]

The XDG defaults put them all (per category like config/data/cache) inside one 'typically hidden' directory, how is that not better?

You're also making an assumption that the alternative is $HOME/.appconfig, which it might be, but that's not any particular standard. It might just as well end up $HOME/app.config or $HOME/Library/Application Support/MacOs/Resources/App.app/config/Config/Resources/config.

[comex]

The kinds of programs that were putting in entirely nonstandard paths (~/app.config), or paths specific to macOS or Windows, are still doing that.

But when it comes to a 'well-behaved' Unix program, there used to be one place to look for its configuration, and now there are three.

That is, a program foo could still have its configuration in ~/.foo, but now it can also have it in ~/.config/foo or ~/.local/share/foo. If I don't know where the configuration is already, I have to check all of them.

I know ~/.local/share is supposed to be for "data files" and ~/.config is supposed to be for "configuration files", but in practice the distinction seems to be rather unclear.

Also, ~/.local/share/foo is a lot slower to type than ~/.foo even with tab completion. Why does that path need to be two directories deep? ~/.config/foo is less bad but still slower.

[account42]

With the XDG Basedir Spec you don't have to use ~/.local/share and ~/.config if you don't like them, they are just the defaults after all and you can set the respective environment variables to whatever you want. That is not an option you had before.

Admittedly, it would have been nice if the variables were defined in a way that let you reproduce the traditional dotfiles, e.g. by pasting $XDG_DATA_HOME in front of the app name so you could set XDG_DATA_HOME=$HOME/. and requiring an explicit trailing slash if you want them to be a directory.

[OJFord]

Sounds like your issue's more with change than specifically what the spec says then. I get that, but also.. where would we be? (But then, I use a rolling release distro (btw) and happen to like systemd.)

> Why does that path need to be two directories deep?

It doesn't, set `$XDG_DATA_HOME` to something that isn't.

[benatkin]

Eh, for me it's that it's a grouping I don't like. I would really rather have the config and data bundled together. It's kind of like OOP where the functions and data are bundled together.

[lmm]

> The XDG defaults put them all (per category like config/data/cache) inside one 'typically hidden' directory, how is that not better?

Because it puts them in an overengineered, overly cumbersome hierarchy under that. It reminds me of OSI.

> You're also making an assumption that the alternative is $HOME/.appconfig, which it might be, but that's not any particular standard. It might just as well end up $HOME/app.config or $HOME/Library/Application Support/MacOs/Resources/App.app/config/Config/Resources/config.

Either of the first two is easier to work with than the XDG-compliant way, and the last is no harder.

[memetomancer]

FYI, and nothing personal, but your comment is more or less coming across to me as "whelp, the inflexible delegation has spoken".

I go to great lengths to maintain a flexible mindset, to try to get the best out of a new approach. Hearing/reading someone trying to throw a shallow take-down of something they haven't tried doesn't read as "ooh that person is so cool I'm super convinced"... it comes across more like "oh, poor fella went and got his brain rigidized... and at such a young age".

But maybe you'll come around. Maybe people will come around and realize the ankle-deep hot takes are worse than useless and we can all get back to the good stuff.

On the other hand, I do have my own suspicions. At first glance it does simply sound like another layer of idiosyncrasy to jam into the memory hole, something that will certainly never be universally adopted and just add more hidey-holes to search for config files.

But, as I hope I made clear, I'm willing to give it a shot because I don't trust myself to have absolute insight into a thing after a couple minutes reading. There may well be aspects to this that I can't conjure, but will really like after all is said and done.

[lmm]

> Hearing/reading someone trying to throw a shallow take-down of something they haven't tried

I mean, I've lived with XDG messing up where my config files are for several years at this point. How much "trying it" do I have to do to be allowed to have an opinion?

[chimprich]

> I mean, I've lived with XDG messing up where my config files are for several years

Why don't you set your XDG vars to where you want to put them then?

What's your alternative? Force everyone to follow your preference instead of having it configurable?

[rkta]

> Why don't you set your XDG vars to where you want to put them then?

I hear that argument often. When a program uses $XDG_CONFIG_HOME/tool/ for its config files, to what value should I set XDG_CONFIG_HOME to get the old behavior where it puts its config in $HOME/.tool/?

[chimprich]

That's an interesting question, and I don't know the answer. A Google search and ChatGPT request provide no answers, so this seems like an uncommon request. It seems like there ought to be a way to achieve this reasonable request though.

Possibly setting it to $HOME would make all/most programs assume that you wanted it to live in $HOME/.tool rather than $HOME/tool, but I'm guessing. I don't know if that's the standard.

[yjftsjthsd-h]

> an overengineered, overly cumbersome hierarchy under that.

You put config files in $XDG_CONFIG_HOME/app/whatever with a fallback to $HOME/.config/app/whatever, and data files in $XDG_DATA_HOME/app/whatever with a fallback to $HOME/.local/share/app/whatever - what exactly is over engineered or cumbersome about that?