Dotfiles Considered Harmful

Introduction

If you are on a *NIX system, chances are your home directory is full of dotfiles (files whose names start in a dot) containing settings and initialization scripts for various packages. I think those dotfiles are a bad idea, and should be replaced with a more elegant system.

The Problem

To make programs more flexible and useful, they can often be made to behave in a number of ways. A common way to accomplish this is through command line options. Many options will have the same value on most, if not all, invocations. It w ould be tedious to have to type in the same arguments on each and every invocation. We want to store the commonly used options, so that they will be automagically applied each time the program is invoked, and preferably allow the stored options to be overidden when needed.

Some options are site-specific (e.g. the location of certain executables) and have the same values for each user on the system. Other options are more a matter of preference, and can be different for every user. We thus need a mechanism that allows us to store the preferences of each user separately. It is possible to store the sitewide options in for each user, but it's preferable to store them in a central location, so that they can be changed in one place for all users at once if the need arises.

Aside from options, some programs have initialization scripts, that specify certain actions to be taken when the program is started. An example of this is the X Window System, which typically launches a number of clients when the server is started. Here, again we want to be able to store the preferences for each user, while it can also be useful to have sitewide defaults.

The Kludge

On NIX systems, users do not have unrestricted access to all files on the system. Each user has a home directory (typically /home/username), in which they can do pretty much anything they please. Most files outside this directory can be read, but not written by regular users. It makes sense, then, to store the user preferences in their home directories. However, the canonical way of doing this on *NIX systems is somewhat of a kludge.

User preferences are stored in files inside the user's home directory. This means that this directory is full of files that the user usually doesn't want to see. After all, configuration files are used for saving options that are commonly used, and should thus rarely need changing. In order not to bother the user by showing the files each time the contents of the directory are listed, the convention is to start their names with a dot (for this reason, they are often called ‘dotfiles’). The leading dot keeps most utilities from displaying the files (unless certain options are set). The files are still there, still accessible, but they won't get in the way.

The problem with storing preferences in dotfiles is that they are often overlooked by users. This is indeed the purpose of prepending a dot to the filename, but it can have annoying consequences. A few years ago, I was using two different machines, each with different software installed (one was running Slackware, the other OpenBSD). I kept most of my files synchronized between the two systems using rsync. All was well, until I (in a not so bright mood) decided to rsync my whole home directory at once, instead of each subdirectory seperately. This also brought my dotfiles into sync, leading to various annoyances such as my clients no longer being able to connect to the X server.

The opposite issue (not copying the dotfiles when I should have) has also bitten me recently. When making backups, I don't want to archive my download and temp directories, so I specify the directories to be archived, rather than archiving my entire home directory. When my hard disk crashed sometime ago, I discovered that this did not include, among other things, my mutt configuration and my PGP keys, which are stored in dotfiles.

Aside from my personal bad experiences with dotfiles, I think hidden files are ugly in general. I got a lot of my experience by writing programs against public APIs on systems whose source code is publicly available, and writing drivers for hardware whose specifications I looked up on the Internet. Without all this information being openly accessible to me, I wouldn't know what I know today. The whole concept of hiding things from the user is alien to me, and hiding the user's own preference files from him seems outright wrong. I think there is a better way.

The Solution

Instead of putting preferences directly inside the home directory, why not create a subdirectory (e.g. settings) and put them in there, as regular, visible files? That way, there is only one extra item in the listing of the home directory, and it serves a useful purpose. When the user looks for the settings, they can easily be found by looking inside the designated directory. Never more will you be surprised to find your settings overwritten, because you forgot to take into account the hidden files in your home directory. Never more will you forget to back up your settings because you didn't see them.

Putting settings in a designated directory seems far superior to dotfiles. They both solve the problem of cluttering the home directory, but the settings directory solves the problem at its root: it simply doesn't put the files in the home directory in the first place, so it doesn't need a kludge to hide the fact that they are there. This is more elegant, and has the additional benefits that settings are readily discoverable, and harder to overlook.

Alternatives

TBD