Dotfiles are everywhere. If you have used a Linux system for some time, I am sure that you have come across this horrendous dotfiles infesting your home directory. A simple ls -la in my home directory lists at least 70 such files and directories on my system. These are files and directories that I did not create, and if I delete them, they will reappear in due course.
Dotfiles are configuration files used by a variety of programs to store their configuration data. A program creates a dotfile on the first run and all subsequent executions of the program loads its configuration settings from these files. Users can customize and tune these dotfiles to meet their individual requirements and liking. Most Linux users spend a considerable amount of time customizing their dotfiles to suit their personal preferences. These custom configurations follow the user across all devices that the user has access to. In the follow-up article, I will show you how you can manage your dotfiles elegantly.
So why is it that nobody has tried to fix this problem? Well, for historical reasons, backward compatibility and a bunch of other reasons, we cannot get rid of dotfiles; However, we can bring in some sanity in its creation and management. There have been commendable attempts at solving this problem. The XDG Base Directory Specification defines a set of configurable environment variables to dictate where programs should store their configuration and data files. If we do not set these variables, the specification even specifies the default fallback locations. The problem is that developers do not adhere to these specifications, leaving you and me fuming over this dotfile infestation.
User Specific Environment Variables
As defined by the XDG Base Directory Specification, we need to set the following user variables:
$XDG_DATA_HOME
$XDG_DATA_HOMEdefines where user specific data should live. This includes data such as user emails, browser plugins, history, bookmarks and so on. If the user has not configured this variable, the developer should fallback to $HOME/.local/shareto store the required data.
$XDG_CONFIG_HOME
$XDG_CONFIG_HOMEshould contain all user specific program configurations. This includes default configurations of a program and any customizations made by the user. $HOME/.configis the fall back location defined by the specification.
$XDG_CACHE_HOME
$XDG_CACHE_HOMEis the home for all files cached by various programs. Your browser cache, data generated by streaming services, thumbnails generated by file managers and so on should live at this location. If the user has not set this variable, then the programs should fall back to $HOME/.cacheto store this data.
$XDG_RUNTIME_DIR
$XDG_RUNTIME_DIRdefines the directory where programs need to store all runtime files. This includes information such as sockets and pipes required for inter-process communication.
System Level Environment Variables
The XDG Base Directory Specification defines certain variables for system-wide configurations.
$XDG_CONFIG_DIRS
Quite a few programs have defaults for all users of the system. Users can override these configuration files to customize these settings as per their preference. The $XDG_CONFIG_DIRSis the home for such system-wide configuration files. If the user has not set this variable, the XDG specification defines /etc/xdgas the default location for all such configurations.
$XDG_DATA_DIRS
$XDG_DATA_DIRSshould store all data files any user on the system can use. This directory is complementary to the user $XDG_DATA_HOMEdirectory. If the user does not configure the $XDG_DATA_DIRSvariable, the system should default to the /usr/local/share/:/usr/share/location.
So where does this all lead to? The standard and the guidelines specified are easy to follow. I believe that the developer community needs to adhere to these specifications. Making a change to incorporate these standards should not be difficult for developers of existing programs, and it will be much easier for new developers to adhere to these standards. Users need to regain control of their home directories. It is our collective responsibility to bring order to this dotfile madness.
