[upofadown]

Yeah, we have a straightforward and widely established standard. Just put the related files in .programname .

Now let's bikeshed and scatter them randomly across several places. To make it more fun let's make those locations programmable with environment variables so you won't even know where to start looking for a particular related file. Add lots of categories to create ambiguity. Make some of the default locations single level and others multiple level directories for no apparent reason for extra fun.

[weberer]

>let's make those locations programmable with environment variables so you won't even know where to start looking for a particular related file

What? Just use the environment variable when reading.

[account42]

That has never been a standard as many programs have multiple dotfiles in ~. But even if it was, there are still good arguments for the XDG Basedir Spec: common way to change the location via environement variables as well as ability to split cache and non-cache.

[simiones]

Having this depend on env vars is an anti-feature in my mind. It's much harder to ensure env vars are set to the "right" values in all situations then it is to just use some well-known paths.

[yesco]

Come on, you just use a fallback if it's unset, you can even use your "well-known" paths for that if you want to. Don't pretend this harder than it actually is! This is like lesson 1 to using environmental variables, it's like saying you never free your mallocs because it's "much harder" that way! The OP site even provides code examples for popular languages, how can you imply that randomly littering your user's $HOME directory is the viable alternative here?

[subsection1h]

> Now let's bikeshed and scatter them randomly across several places

"Now"? The initial draft of the XDG Base Directory Specification was published in 2002.

I don't my backups to include gigabytes of worthless cache files. I want them isolated somewhere, anywhere, so they can be easily excluded in my backup scripts.