I find it useful; I might want to version-control .config but definitely not .cache. And if the program is broken I might blow away .cache but not .config.

That still works if it’s `~/.foo/cache`

    rm -r ~/.foo/cache ~/bar/cache ~/baz/data/app/cache [20 more apps..]

is less ergonomic than

    rm -r ~/.cache/\*

I think HN escaped the * in that final line before I edited it into a code block and my edit window is expired so I can't fix it

There’s always:

    rm -rf ~/.*/cache

Assumes the app uses cache as it's cache, rather than names like dlcontent, bananas_content, storage.sqlite, assets, meta, $TIMESTAMP.txt etc.

Well, I don’t mind standards, I just prefer all the files an app touches to be under a single root folder (that’s not just $HOME)

Asked out of ignorance, but do the envvars not allow one to easily co-locate data/config/cache by setting them all to the same value?

Not in a way that would be useful here, I think: I prefer ~/.firefox/cache to ~/.cache/firefox and this requires the variables being unique per program (although, you could probably wrap each program with a script that sets the relevant environment variables to achieve this effect)

I was thinking along the lines of ~/.data/{prog} without requiring further subdirs. The config, data, and cache would all coexist within the same directory per program

Each of the data, config, and cache envvars would all be set to ~/.data in this setup (though “data” isn’t a name I’d use)

It is convenient because you can delete ~/.cache any time without losing configuration files.