This is my collection of user/application settings ("dotfiles") and personal scripts. They are mostly adapted to my personal needs, and some scripts make a few assumptions about the environment that may not necessarily be considered "standard", so it is not recommended to just copy-paste them as-is.
Nevertheless, I try to keep them as clean and non-WTF as possible, and people are invited to take a look at them, get ideas for their own dotfiles, and drop comments, suggestions, questions and bug reports if something seems odd.
My goal is to keep the top-level user home directory as clean as possible by
honouring the XDG base directory specification, adapted to
recreate the Linux file system hierarchy (FHS) under ~/.local
. In
detail, this means that the following environment variables are set:
Variable | Location |
---|---|
XDG_CACHE_HOME |
~/.local/var/cache |
XDG_CONFIG_HOME |
~/.local/etc |
XDG_DATA_HOME |
~/.local/var/lib |
XDG_RUNTIME_DIR |
~/.local/run |
XDG_LIB_HOME |
~/.local/lib |
XDG_LOG_HOME |
~/.local/var/log |
XDG_LIB_HOME
andXDG_LOG_HOME
are non-standard, but they are nevertheless necessary for representing the FHS locally.~/.local/var
and~/.local/run
are technically not supposed to be on this level (as this is a variant of/usr/local
), but for simplicity's sake, I keep them there as well.~/.local/run
must be a symbolic link to/run/user/<uid>
.- Some applications unfortunately do not honour the XDG basedir specs, so I additionally set environment variables or write wrapper scripts—or simply weep (see also issue #7). The XDG Base Directory support article in the Arch Linux wiki contains a list of applications that honour the specs (or can be made to do so).
Furthermore, the $PATH
variable is expanded to contain the following
locations (assuming that this repository has been cloned into
~/.local/lib/dotfiles
):
Location | Description |
---|---|
~/.local/bin |
User-specific executables (not tracked) |
~/.local/lib/dotfiles/bin |
User-specific executables provided by this repository |
~/.local/lib/utils/bin |
User-specific executables provided by the utils repository |
~/.local/opt/altera/... |
Various paths containing Altera Quartus II-specific executables |
For using the dotfiles, I clone this repository into ~/.local/lib/dotfiles
,
and then symlink each file/directory to their respective locations:
~/.pam_environment
→~/.local/lib/dotfiles/pam_environment
~/.local/etc
→~/.local/lib/dotfiles/etc
~/.local/lib/argyll
→~/.local/lib/dotfiles/lib/argyll
~/.local/lib/python
→~/.local/lib/dotfiles/lib/python
~/.local/lib/urxvt
→~/.local/lib/dotfiles/lib/urxvt
~/.local/run
→/run/user/{uid}
For Arch Linux systems, there is a PKGBUILD that creates a meta-package to pull in the required packages.
The dotfiles have primarily been used on Arch Linux (and for limited use-cases on Debian, too, although there are minor issues with tmux and major issues with PAM, both related to Debian shipping antique versions of software).
-
For setting the XDG basedir variables I use
~/.pam_environment
, which is read by PAM. If other authentication frameworks are used, these dotfiles will not work as-is (but with some additional fiddling in the shell initialisation, it should still be doable). -
/usr/sbin
,/sbin
and/bin
are generally assumed to have merged into/usr/bin
, so all absolute paths to system-widely available software point into/usr/bin
by default (note that this is a more extreme case of the/usr
merge). Nevertheless, I strive for compatibility with non-Arch Linux systems (even if I consider the distinction of those paths to be absolutely unnecessary), so please let me know when a path should point somewhere else. -
Lots of configuration files will attempt to run scripts and binaries in
~/.local/lib/utils/bin
, provided by the utils repository. The missing of latter should be non-fatal, though.
-
Application history generally goes into
XDG_DATA_HOME
(see commit f1147a9 for the reasoning). The only things that go intoXDG_LOG_HOME
are "real" logs, i.e. data that is no longer read and used by the application itself. The only things that go intoXDG_CACHE_HOME
are files that are non-essential and can quickly be regenerated by the application, if needed (which is both not the case for history files). -
Applications whose configuration is mixed up with other data (or generally not supposed to be manually edited) is put into
XDG_DATA_HOME
, reason being that I would like to trackXDG_CONFIG_HOME
with git as much as possible. This of course only works for applications that allow configuring the location of "config" files. -
Shell-agnostic configuration should happen in
XDG_CONFIG_HOME/sh
. This allows other, non-zsh shells to work correctly, too, without having to duplicate all the shell configuration. The shell-agnostic configuration is stored inenvironment
,login
andconfig
as well asprofile
and theprofile.d
directory for application-specific profile snippets, while only shell-specific configuration (prompts, input, history, etc.) should happen in zsh's config. -
Although shell aliases are generally more lightweight than wrapper scripts, wrapper scripts allow being used also from a non-shell environment (or with
sudo
). So it mostly depends on the application whether we create aliases or wrapper scripts for them.
As noted above, these dotfiles represent my personal setup—nevertheless, I encourage people to take a look at it, mainly for learning how applications can be made to (somewhat) conform to the XDG base directory specifications (and thus have a clean home directory).
There are other, similar "experiments" out there: