Personal configuration files
Switch branches/tags
Nothing to show
Clone or download


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 (see also this issue), 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/tmux~/.local/lib/dotfiles/lib/tmux
  • ~/.local/lib/urxvt~/.local/lib/dotfiles/lib/urxvt
  • ~/.local/run/run/user/{uid}
  • ~/.local/var/lib/applications/mimeapps.list../../../etc/mimeapps.list


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).

Minimally expected software is git, PAM, systemd and zsh, for a basic (headless) setup.

/usr/sbin, /sbin and /bin are assumed to have merged into /usr/bin (note that this is a more extreme case of the /usr merge).


  • 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.

  • 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).

  • 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 from any environment (not just interactive shells). 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: