Personal configuration files
Shell Perl Vim script C Python
Switch branches/tags
Nothing to show


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 and XDG_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 into XDG_LOG_HOME are "real" logs, i.e. data that is no longer read and used by the application itself. The only things that go into XDG_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 track XDG_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 in environment, login and config as well as profile and the profile.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: