On unix, most packages put their user configuration files directly in the user's home directory, as specified by the $HOME environment variable. To prevent this from conflicting with the user's files, all configuration filenames start with a dot by convention, giving rise to the notion of dotfiles. But even though this convention works, it makes the user's home directory very messy indeed.
Some packages' authors thankfully understand this, and allow custom dotfile directories to be set either in environment variables (probably the most optimal solution) or by using command line argments. Sadly the extent to which this is done is not really high enough to enable one to have a dotless home directory, but this document discusses various approaches that one can take to at least make some programs do the right thing:
Note that though programs such as ls will ignore dotfiles unless you tell them to do otherwise, many people that I know automatically use the option to show dotfiles because the notion of "hidden" files is disturbing. The fact remains that though the convention works, it's a workaround for the better solution, which would be to read from a custom per-user configuration directory.
How to set up specific programs to use dotfiles in custom locations.
Use --rcfile file on the command line. Set the HISTFILE environment variable to use a history file.
From man bash(1): "--rcfile file Execute commands from file instead of the system wide initialization file /etc/bash.bashrc and the standard personal initialization file ~/.bashrc if the shell is interactive (see INVOCATION below)." Sadly, if you're using a login shell you're probably screwed.
Also from man bash(1): "HISTFILE The name of the file in which command history is saved (see HISTORY below). The default value is ~/.bash_history." And, interestingly enough, it won't save a history file at all if this variable isn't set, so there is no ~/ default.
Impossible without patching (uses ~/.cvspass)?
Impossible without patching (uses ~/.nanorc).
Could possibly be hacked by using $SYSCONFDIR, since it'll read from $SYSCONFDIR/nanorc first of all... Shame herefiles aren't common yet, because that'd be a pretty fun hack.
This is actually pretty annoying, so I've patched nano in the interim. It's quite easy to do: nano-1.2.5.patch (patch -p0 < nano-1.2.5.patch). Then you can set the DOTDIR environment variable.
For cpan, normally ~/.cpan/CPAN/MyConfig.pm is created whatever you do, and then it asks for a custom directory to install to. But you can get around that using the following hack...
$ perl -MCPAN -eshell /home/username/.cpan/CPAN/MyConfig.pm initialized. Are you ready for manual configuration? [yes] no $ mv .cpan mycpan $ perl -Imycpan -MCPAN -eshell
Obviously, you should use your own path instead of "mycpan" in the above example. It will then prompt as usual for a place to put all the CPAN build files, and you can choose the same location as the "mycpan" substitute, or presumably somewhere else if you like.
Set the INPUTRC environment variable.
From man readline(3): "Readline is customized by putting commands in an initialization file (the inputrc file). The name of this file is taken from the value of the INPUTRC environment variable. If that variable is unset, readline will read both /etc/inputrc and ~/.inputrc."
Impossible without patching (uses files in ~/.ssh)?
Use -u vimrc on the command line.
"A shell alias can be used to make this easy to use. For example: alias vimc vim -u ~/.c_vimrc !*" - Vim documentation: starting. See also starting: .vimrc.
Issue: what about ~/.viminfo? That doesn't seem to be configurable, and though you can turn it off that's a bit of a nuisance.
Set the ZDOTDIR environment variable.
From man zshall(1): "Commands are then read from $ZDOTDIR/.zshenv. If the shell is a login shell, commands are read from /etc/zprofile and then $ZDOTDIR/.zprofile. Then, if the shell is interactive, commands are read from /etc/zshrc and then $ZDOTDIR/.zshrc. Finally, if the shell is a login shell, /etc/zlogin and $ZDOTDIR/.zlogin are read."
So the question becomes: if dotfiles shouldn't go in ~/, where should they go? Obviously the whole point of this exercise is that the user gets to decide, but seeing what conventions other people have used can help one to decide given that you have to make the decision anyway.
On OS X, the system sometimes uses ~/Library/Preferences for some things but ~/ for others, depending again on the package. Personally I don't like the way that OS X takes up several directories in my homedir (surprise, surprise), not least because of the use of capital letters, so I prefer not to use this convention. I've been wondering about the use of ~/local/etc for per-user configuration files, since I often use --prefix=/home/sbp/local on systems where I can't install packages into /usr/local.
Daniel "deltab" Biddle, in a conversation very much along the lines of this document, noted that he uses ~/etc/ for some things; and at the time I noted that I was using ~/config/, which deltab thought more logical, though I've since given up on that (or, apparently, had already done by that point). One of the solutions offered by deltab was that of union mounts, e.g. making ~ = ~ + ~/etc.
As you can see, there isn't much consistency amongst the approaches so far: most of the packages above require using a command line argument or setting a specific environment variable. Adding the capability to read from the default filename but in the diectory specified in the $DOTDIR environment variable would probably be the best approach in any new code.
Sean B. Palmer, inamidst.com