One really annoying argument I got when evangalizing this spec (trying to, anyway...) was "the XDG basedir spec is only made for GUI apps". Which is absolutely ridiculous - git and htop both follow it since several versions as well as a bunch of other command line apps now.

I also often hear it's confusing and hard to follow correctly (which is true) so I'll make it simple: if you are an app author now, please don't use dot files in $HOME. Instead:

* ${XDG_CONFIG_HOME:-~/.config}/<appname>/ for your app's configuration directory

* ${XDG_CACHE_HOME:-~/.cache}/<appname>/ for your app's cache directory (in other words, all files which are safe to delete at any time without impact)

* ${XDG_DATA_HOME:-~/.local/share}/<appname>/ for your app's data files directory. If you're confused about what this is, just use the former two, no big deal.

don't forget $XDG_RUNTIME_DIR for sockets and the like

Nobody really uses that outside of pulseaudio/dconf/systemd.

One of the best zsh tweaks I've done was setting

    ZDOTDIR="${XDG_CONFIG_HOME}/zsh"

in `/etc/zshrc`, then moving all miscellaneous files to the same place:

    # ~/.config/zsh/.zshenv
    export HISTFILE="${ZDOTDIR}/history"
    
    # ~/.config/.zshrc
    compinit -d ${ZDOTDIR}/zcompdump
    zstyle ':completion:*' cache-path "${ZDOTDIR}/cache"
    ## separate files for easier and quicker editing:
    for file in $ext_files; do
        [[ -f ${ZDOTDIR}/${file} ]] && source ${ZDOTDIR}/${file}
    done

This method removed quite a few files (history, compdump, cache, zkbd, zshrc, zshenv, zprofile, zlogin, etc.) from my home dir.

I'm sure bash has something similar, but like you said, it would be nice if programs didn't junk up $HOME by default.

> One of the best zsh tweaks I've done was setting

    ZDOTDIR="${XDG_CONFIG_HOME}/zsh"

Congratulations, you have just broken your zsh configuration. $XDG_CONFIG_HOME may not be set (e.g. when logging with SSH or in console, and even not always in X11).

First off, my shell is not broken. Secondly, my post was highly simplified because obviously I'm not going to include the entirety of every single config file my shell uses. All it takes to avoid this "problem" is a single if-statement, or you can just set the var in /etc/profile or with PAM.

I guess I assumed people would not read my post and then start editing a system-wide shell config file unless they knew what they were doing.

But if someone did manage to "break" their shell this way, recovery would be trivial because they will still be able to login and the shell will still run, they just might not have all of their configs loaded.

Thats a systemd-ism, iirc.

I'm torn about this. Some XDG-aware applications use a very convoluted sequence of subfolders to end up placing just a dotfile.

Whereas classical Unix applications simply have one easy to identify dotfile in ~/.

Exactly so. What's the point of moving dot files / configuration files away from $HOME, but only end up having a complex directory structure that stores what you can already do with dot files?

It may be subjective. I don't like the XDG specs. Have you peeked in to OS X $HOME/Library? That's what you end up having. (Let's not talk about windows registries, but I guess systemd people like it.) Is that any better than dot files under $HOME? Hardly so.

I prefer the xdg variables mostly for $XDG_CACHE_HOME and $XDG_RUNTIME_DIR. Those are the kinds of things I don't want to keep having to write rules to exclude from my backups.

Neovim[1] implements the XDG spec.

[1] https://neovim.io

And the best is if programs don't need any config files.

How else would you save state between program runs? Config files don't preclude the application from having the ability to modify config from within the application. Not having config files (or some equivalent) does preclude saving state. Do you think it would be better to save state to a database or binary state file? I do not think it would be better. I prefer YAML config for most everything.

I think that's a bit of a generalisation :)