[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.