Penguin
Recent Changes
Annotated edit history of DotFile version 11, including all changes. View license author blame.
Rev Author # Line
4 LawrenceDoliveiro 1 This term is a wonderful demonstration of Unix at large being an organically grown system that was shaped and moulded as its users' habits built upon each other. It is the colloquial name for a file that stores some of a user's settings or preferences for a specific application or a class thereof. The name derives from the fact that they're commonly stored in a file or directory whose name starts with a dot, located directly under the user's home directory. This became a convention because of the larger convention that filenames starting with a dot be treated as hidden, although there's nothing actually special about them. This was originally a simple heuristic to avoid having the special <tt>.</tt> and <tt>..</tt> directories show up in every file listing.
1 AristotlePagaltzis 2
3 AristotlePagaltzis 3 Examples of DotFile~s can be seen in SampleConfigFiles.
4 LawrenceDoliveiro 4
5 Unfortunately, dotfiles have led to the chronic phenomenon of __dotfile clutter__. Do an <tt>[ls|ls(1)] -lA</tt> on a typical user’s home directory, and you will likely see dozens of names beginning with dots. This has a few unfortunate effects:
6
5 LawrenceDoliveiro 7 * Lack of privacy. If the user wants to make some files readable to other users on the machine, those files have to be put in a directory which is readable by those other users. But in order to access that directory, its parent directory also has to be readable by those users. And its parent, as appropriate, and so on right up the user’s home directory—the one containing all these dotfiles. So other users can at least see the names of those dotfiles, if not their contents, and thereby deduce what applications it’s likely you’re using. And it’s surprising how many of these items are created world-readable, so other users ''can'' see their contents.
6 AristotlePagaltzis 8
10 AristotlePagaltzis 9 ''Other users need execute permission to traverse a directory, but they don't need read permission for it. Of course DotFile~s by and large have guessable names, so if you can traverse a user's home directory you can read their DotFile~s by blindly trying names like <tt>.bashrc</tt>. But note also that almost all of these files can be [chmod|chmod(1)]ded to non-world-readable with no drawbacks. In other words, this is near as big a concern as the above paragraph makes it out to be. —AristotlePagaltzis''
11 AristotlePagaltzis 10
11 ''Assuming you remember to do that. Which still doesn’t change the fact that knowing those files exist already gives information away. –LawrenceDoliveiro''
12
13 ''You mean: Other users need read permission to list the names of items in a directory and execute permission to actually access those items. –LawrenceDoliveiro''
14
15 ''No. I meant exactly what I wrote, and it is correct. To access <tt>/home/ap/www/index.html</tt>, you need to traverse the root directory, <tt>home</tt>, <tt>ap</tt> and <tt>www</tt>, in order to get to <tt>index.html</tt>, so you need execute permission on each of those directories, but need read permission only on the file. —AristotlePagaltzis''
6 AristotlePagaltzis 16
4 LawrenceDoliveiro 17 * Untidiness. Anything the user wants to create, has to be found by starting from the top level of their home directory. So at this top level, you have a whole bunch of items mixed together, some created explicitly by the user, others implicitly by apps run by the user. Yes, directory-listing utilities commonly offer the option to hide dotfiles and just show the others, but the opposite option seems a little harder to achieve.
5 LawrenceDoliveiro 18
19 For these reasons, it seems a good idea to give the user more control over where these preference files are created. The only serious proposal I know of is the [XDG Base Directory Specification|http://standards.freedesktop.org/basedir-spec/latest/]. This says that user prefs should be created in the directory specified by the EnvironmentVariable <tt>XDG_CONFIG_HOME</tt>. If this is not defined, then the prefs should go in the directory <tt>$HOME/.config/</tt>. The directory should be created if it doesn’t exist, to be readable and writable by the owner but inaccessible to anyone else.
20
10 AristotlePagaltzis 21 Thus, all the dotfile clutter is replaced by a single dotted-directory name, and the user has the option of overriding even this.