For most Linux distributions, even in a pristine bare minimum installation, the home directory of a user is already littered with a bunch of files and directories, that contain program configurations, colloquially called dot-files. This gets worse over time, as more programs are installed and used.
First of all, the visual clutter of a mass of dot-files and directories is heavily distracting. To get this visual clutter out of your way is big plus.
Second, organizing your data files in respect of data type helps running your backups faster and keeps your backup files smaller. I don’t find it particularly useful for my backups to include stuff like image thumbnails or my web browsers cache. In case of a data loss, such data is automatically reconstructed on the fly (i.e., image thumbnails) or not of much importance (i.e., a web browser’s cache).
The XDG Base Directory Specification defines a set of locations in a user’s home directory where programs should look for and place user specific files, i.e., configuration files, cache files, state files, runtime files, and application data. These locations are defined by environment variables that start with . All but one of these env vars have a default value, and can be set to user-specific values.
I will occasionally refer to the corresponding sections of the techdoc page for the XDG Base Directories specification on this site.
The XDG base dirs perfectly suit the mission goal of an uncluttered, clean home directory. Unfortunately, getting an uncluttered, clean home directory in Linux is not a straight forward action. Adoption of the XDG Base Directory Specification by programmers that write tools and programs for *nices, respectively Linux, is pretty low.
For programs that follow the XDG base dir spec, the procedure is to read the respective env vars, and, in case the env var is not set or is empty, to use the respective default value defined in the XDG base dir spec. The spec does not define a default value for , which leaves little room for arbitrary choice ( is a good choice for runtime files).
I always suspected that programs that don’t adhere to the XDG base dir spec just evaluate the env var and dump their stuff right into it. Until the xscreensaver man page told me so:
" ENVIRONMENT
....
HOME for the directory in which to read the .xscreensaver file. "
xscreensaver man page
runs a command in a modified environment. With , the music player qmmp, a simple drop-in replacement for the long gone xmms, drops its files into . If you wonder about the name of the directory:
However, misbehaving programs that only write one type of data, i.e., a config file, can be redirected with to the suitable XDG base dir, as is the case in xscreensaver, which just writes the config file . I’m rather happy about this one, and xscreensaver is my screen saver of choice for decades. Would be hard for me to find a replacement for that one.
| config var | default | usage |
|---|---|---|
| XDG_CONFIG_HOME | $HOME/.config | user-specific configuration of application programs, i.e. text processors and spreadsheets like libre office, graphic programs like GIMP. The user-specific XDG base dirs config files must be located here. |
| XDG_DATA_HOME | $HOME/.local/share | the XDG spec states that this location is for user-specific data files, but doesn’t specify what kind of data. |
| XDG_CACHE_HOME | $HOME/.cache | user-specific non-essential (cached) data. Data that speeds up operations but is not essential for functioning of the program, i.e. a web browser’s cache. |
| XDG_STATE_HOME | $HOME/.local/state | user-specific state data; actions history (i.e. command history, recently used files) and application state (i.e. view layout, open files) |
| XDG_RUNTIME_DIR | user-specific non-essential runtime files and other file objects such as sockets and named pipes. Data for program communication and synchronization purposes. | |
| XDG_CONFIG_DIRS | /etc/xdg | preference-ordered set of base directories to search for configuration files in addition to , with the directories separated with a colon ‘:’. |
| $HOME/.local/bin | user-specific executable files. |
The XDG base dir spec list a lot of requirements for . I always ignored the requirement that the directory must be destroyed when the user logs out and used a location inside . is cleared during shutdown/reboot. An alternative is using a location on a RAM disk for runtime files, i.e.:
The notion in the XDG base dir spec that “Distributions should ensure this directory shows up in the UNIX $PATH environment variable, at an appropriate place.", without the possibility for configuration, is quite patronizing. I’m not a fan of user-specific executables anyway. is good enough for me.
xscreensaver man page, section Environment
Oracle Java SE 8 Documentation, The JAVA_TOOL_OPTIONS Environment Variable