Madness of dotfiles

https://0x46.net/thoughts/2019/02/01/dotfile-madness/
  • Transfer
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 perform ls. I have no idea how my personal folder directory were node_modulesfiles package-lock.json, yarn.lock(I have never knowingly even putyarn!), some two strange log files from some Java program that explicitly uses the H2 database, and a folder Desktop. 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 user directory $HOMEto 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_HOMEdefines the base directory in which user data files should be stored. If $XDG_DATA_HOMEnot defined or contains an empty value, then the default value should be equal $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_HOMEdefines the base directory in which user configuration files should be stored. If $XDG_CONFIG_HOMEnot defined or contains an empty value, then the default value should be equal $HOME/.config.

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_HOMEdefines the base directory in which non-essential (cached) user data should be stored. If $XDG_CACHE_HOMEnot defined or contains an empty value, then the default value should be equal $HOME/.cache.

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_DIRSdetermines the order of preferences for the base directories in which configuration files will be searched, in addition to $XDG_CONFIG_HOME. Directories in a variable $XDG_CONFIG_DIRSmust be separated by a colon.

If $XDG_CONFIG_DIRSnot defined or contains an empty value, then the default value should be equal /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_DIRSdetermines the order of preferences for the base directories in which data files will be searched, in addition to $XDG_DATA_HOME. Directories in a variable $XDG_DATA_DIRSmust be separated by a colon.

If $XDG_DATA_DIRSnot defined or contains an empty value, then the default value should be equal /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 a directory $XDG_CONFIG_HOME/your-program, 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 work of 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.

Also popular now: