We no longer control our home directories.

In my own 25 regular files and 144 hidden. Dotfiles store data that does not belong to me: they belong to programmers whose programs decide to capture my space, which is intended for storing my personal files.

I can not remove these files to another place. If I try to remove them, they will appear again. All I can do is sit and know that in the dark, behind the scenes, they are. Waiting in silence. Some of these programmers decided to additionally place here a few regular files and directories. They are clearly visible every time I run ls . I have no idea how the node_modules directory, package-lock.json , yarn.lock (I never deliberately even yarn !), Some two strange log files from some Java program got into my personal folder, explicitly using the H2 database, and the Desktop folder. The latter was created by Steam, which is rather unfortunate, since there is simply no desktop or any desktop on my machine. I'm afraid of the day when I hear a loud knock at the door - and one of these programmers will burst in and tell you that he is going to keep some of his furniture in the middle of my living room, if I do not mind.

For those of you who read this: I implore you. Do not create files or folders of any type in the $HOME user directory to store your configs or data. This practice is at least strange, and it's time to stop it. I'm sorry to say that many, if not most programs are guilty of this, while there are significantly better places to store each user's data.

Even if we can never solve this problem - because of historical heritage, backward compatibility, old software versions, or programmers-villains who store files where they want, simply because of harm - we can at least try to follow sane practices. Although the conceptual mistake of introducing "hidden" files is no longer canceled, we can at least mitigate its consequences.

This particular problem has been noticed and solved long ago with the creation of the Specification for the location of base directories (XDG) . It defines a set of environment variables that point programs to the directory in which the data or configuration should be stored. These variables are set by the user, so if they are not specified, the program should use the default directory defined by default, not the user's home directory.

User environment variables

$ XDG_DATA_HOME

$XDG_DATA_HOME specifies the base directory in which user data files should be stored. If $XDG_DATA_HOME not defined or contains a $XDG_DATA_HOME value, then the default value should be $HOME/.local/share .

Example of use: storage of plug-ins uploaded by the user, databases created by the program, input history, bookmarks, emails, and so on.

$ XDG_CONFIG_HOME

$XDG_CONFIG_HOME specifies the base directory in which user configuration files should be stored. If $XDG_CONFIG_HOME not defined or contains a $XDG_CONFIG_HOME value, then the default value of $HOME/.config should be used.

This directory should be used to store custom program configuration files. When you first run the program, it is probably wise to create a file with reasonable defaults.

$ XDG_CACHE_HOME

$XDG_CACHE_HOME specifies the base directory in which non-essential (cached) user data should be stored. If $XDG_CACHE_HOME not defined or contains a $XDG_CACHE_HOME value, then the default value of $HOME/.cache should be used.

Example: caching of preview images from a file manager, songs that a user often listens to through a streaming service, and so on. The program should continue to function without any problems, if this directory is deleted by the user. Make sure unnecessary files are properly deleted. Remember that exceeding your files a reasonable amount of disk space is likely to upset the user, who quickly find the culprit in the face of your program.

$ XDG_RUNTIME_DIR

$XDG_RUNTIME_DIR specifies the directory in which non-essential runtime files and other objects should be stored (for example, sockets, named pipes ...).

The specification lists a number of requirements for this catalog. Indicated that it should be used to store sockets and other files that are used in communications.

System variables

$ XDG_CONFIG_DIRS

$XDG_CONFIG_DIRS determines the preference order for the base directories in which configuration files will be searched, in addition to $XDG_CONFIG_HOME . Directories in the $XDG_CONFIG_DIRS variable must be separated by a colon.

If $XDG_CONFIG_DIRS not defined or contains a $XDG_CONFIG_DIRS value, then the default value should be /etc/xdg .

This directory should be used for system-level configuration files. This configuration can be overridden by user configuration files. Most likely, this directory is used during the installation process.

$ XDG_DATA_DIRS

$XDG_DATA_DIRS determines the order of preference for the base directories in which data files will be searched, in addition to $XDG_DATA_HOME . Directories in the $XDG_DATA_DIRS variable must be separated by a colon.

If $XDG_DATA_DIRS not defined or contains a $XDG_DATA_DIRS value, then the default value should be /usr/local/share/:/usr/share/ .

Example: saving plugins or themes used by all users. Most likely, this directory is used during the installation process.

How does it work in practice?

Using the standard is very simple. Read the corresponding variable, and if it is missing, use the default paths defined by the standard. There, create a directory for the program and store your data.

For example, store configuration files in the $XDG_CONFIG_HOME/your-program directory, and not just in $XDG_CONFIG_HOME . And never write the default path in the program from the standard, but first read the environment variable to allow the user to define these directories if necessary.

You can easily migrate existing programs to use this standard. To do this, when creating new files, start using the standard, but continue to check the old location of the files as they are read. This will allow you to perform the migration without disturbing the program for users with configuration files or data created by a previous version of the program.

Read the standard to learn more and take a look at the directory hierarchy that is almost certainly already present in your home directory. In reality, a cross-platform library is available for your programming language, allowing you to define a directory for storing your data. On Linux and similar systems, this library will most certainly use the Specification for the location of base directories.