You can also use these override the xdg variables as the service or pam runs before the user session is active.

Currently, xinit on its own doesn't quite work as correctly as it used to (either it doesn't start X at all, or it does, but random things like the audio¹ are broken). As a consequence, I have to resort to using startx, which is annoying, because it completely ignores the XINITRC environment variable, and thus my invocation looks something like this:

exec startx .local/etc/X11/xinitrc

The reason for xinit not working correctly on its own is probably related to setting up Xauth and something with the virtual terminal (VT), so some additional arguments are usually required (which startx is there to handle):

grawity > what I've always used is xinit "$@" -- "$DISPLAY" "$vt" -noreset -auth "$XAUTHORITY" -quiet -background none
grawity > $vt being just "vt$(fgconsole)"

Possible ways to improve starting X11 are:

1. Repackage xorg-xinit on Arch Linux to patch in support for the XINITRC environment variable in startx (as this fix would be very Arch Linux specific, certainly also ask upstream to have it fixed globally).
2. Consider switching to earnestly's sx, an alternative to xinit and startx (experimental, according to him).
3. Write an xinit (or even X client&server invocation) wrapper myself.

¹ This is actually really awkward: I get access permission errors for /dev/snd/controlC0 from X, but not in the TTY.

Using wrapper scripts is a really ugly workaround. On systems that don't have the wrapped programs installed (I mean... claws-mail, darktable, firefox, pidgin on a server?) the commands still show up in the auto-complete.

As this is really just workarounds for upstream fixing their software, this merits another todo-list:

• claws-mail: Sets --alternate-config-dir to XDG_DATA_HOME/claws-mail/ [SOLVED: b7d08db]
• darktable: Sets --configdir to XDG_DATA_HOME/darktable/ [SOLVED: af3a4a2]
• firefox: Have it use an alternative HOME directory (also decribed here: #7) [SOLVED: a7bea7f]
• irssi: Has irssi (somewhat) respect the XDG basedir spec + generating the configuration with the password into XDG_RUNTIME_DIR through use of pass.
• mbsync: Has mbsync use XDG_CONFIG_HOME/mbsync/mbsyncrc.
• minecraft: Has Minecraft put its data into XDG_STATE_HOME/minecraft.
• msmtp: Has msmtp use XDG_CONFIG_HOME/msmtp/msmtprc.
• pidgin: Has pidgin use XDG_STATE_HOME/purple/.
• quilt: Has quilt use XDG_CONFIG_HOME/quilt/quiltrc [SOLVED: ccd9c02]
• qutebrowser: Adds dwb-like session handling to qutebrowser.
• sbt: Has ivy2 and sbt use XDG_STATE_HOME/{ivy2,sbt} [Bug report]
• sendmail: Symlink to msmtp wrapper.
• shellcheck: Disables a few warnings [SOLVED: fd4f786].
• sloccount: Dump cache data in XDG_CACHE_HOME and set LANG=C because sloccount otherwise spits out all sorts of errors.
• sudo: Pass -E for launching vim (TODO: this is ugly as hell—find a better way to edit files as root).
• tmux: Has tmux use XDG_CONFIG_HOME/tmux/config.

The link to the utils repository in the readme in the list of location/descriptions is broken, referencing github.co and not github.com

Text is generally easier to read at lower screen brightness if it's dark foreground on white background. This would save energy.

We would ideally have a simple way of switching "profiles" (urxvt has the feature of classes, I'll need to see if this is useful for this case). Vim supports multiple colour schemes (we need to properly export the homebrew colour scheme to a separate file).

On line 92:

URxvt.perl-lib       : /home/ayekat/.local/lib/urxvt/perl/

We'll have to see if it is possible to use environment variables there. This is quite a bit annoying if using the dotfiles for some other user.

It remains to be seen at what point this is usable, but the current xinitrc has clearly become unmaintainable.

Qutebrowser userscripts are stored in $XDG_DATA_HOME/qutebrowser/userscripts, so are unavailable when using your (awesome) wrapper script.

Here's a patch that works for me, by symlinking the userscripts directory into the session dir.

diff --git a/bin/qutebrowser b/bin/qutebrowser
index 942609f..f1ca8fc 100755
--- a/bin/qutebrowser
+++ b/bin/qutebrowser
@@ -69,6 +69,10 @@ if [ $basedir_specified -eq $FALSE ]; then
 	ln -fsT "$XDG_CONFIG_HOME/qutebrowser" "$basedir/config"
 	ln -fsT "$XDG_CACHE_HOME/qutebrowser/$session" "$basedir/cache"
 	ln -fsT "$XDG_DATA_HOME/qutebrowser/$session" "$basedir/data"
+	if [ -e "$XDG_DATA_HOME/qutebrowser/userscripts" ]; then
+		ln -fsT "$XDG_DATA_HOME/qutebrowser/userscripts" \
+			"$XDG_DATA_HOME/qutebrowser/$session/userscripts"
+	fi
 fi
 
 # Search "real" qutebrowser executable:

When running vim with sudo -E vim, backup-, undo-, swap- and other files (e.g. plugins) are created as root. That is usually not a problem, as the containing directories (~/.local/var/lib/vim/{undo,swap}, ~/.local/run/vim/backup) are usually owned by the regular user.

... that is, if the directories have been created by the regular user. For files under ~/.local/var/lib/vim, that would be the first time after the dotfiles have been set up (so this issue generally doesn't really arise), for files under ~/.local/run/vim the first time after the system has booted (this does happen every now and then).

There should be a way to make sure that the permissions on those directories are correct; for the moment, I regularly find myself chowning ~/.local/run/vim/backup if the first invocation of vim after a system boot-up was with sudo, which is a bit annoying.

Currently, a perceived 90% of machines on which I have set up my dotfiles run Arch, so there isn't really any point in printing the distro logo.

Instead, we could add machine-specific logos (e.g. a cherry for chirschi or a blackberry for brombeeri ...). That would be more fun and actually also more useful.

--edit: Obviously, if a node is not matched/unknown, we fall back to distribution logos.

This is the "hard resistance" of hidden files that still remain in my home directory, and for which there is no trivial solution listed in this Arch Wiki article:

• .adobe: Created by flashplugin [FIXED] Flash is dead, see [comments below][c:mozilla]
• .android: Created by adb (Android Debug Bridge) [FIXED] See comments below
• .anthy: Created by anthy (Japanese IM) (bug report) [UNLIKELY] Project appears dead
• .asoundrc.disabled: Ugly hack for changing ALSA soundcard [FIXED] See comments below
• .ivy2: Created by sbt (Scala Build Tool) [FIXED] See 3e7375f
• .macromedia: Created by flashplugin [FIXED] Flash is dead, see [comments below][c:mozilla]
• .mailcap: Created/used by claws-mail and mutt [FIXED] for mutt (5a22d78) but [???] for Claws-Mail
• .mozilla: Created by firefox (and thunderbird) (bug report) [WORKAROUND] See 9c2138b
• .pki: Created by Chromium using libnss (issue), and thus WebEngine
• .rnd: Created by OpenSSL [FIXED] See b604d50
• .sbt: Created by sbt (Scala Build Tool) [FIXED except for ~/.sbt/preloaded [FIXED]] See 3e7375f
• .sqlite_history: Created by sqlite, cannot be configured (discussion) [UNLIKELY] Devs refuse to fix it (but may be open for patches) [FIXED] (upstream)
• .ssr: Created by simplescreenrecorder (Qt4) [???]
• .uim.d: Created by UIM [FIXED] Switched to iBus
• .w3m: Created by w3m [FIXED] See 896234f

Some of them are not essential and can be occasionally purged with dotbloat, but some others (.anthy, .mailcap, .pki and .ssh) are permanently required, and thus more annoying.

Explicitly not listed

The following 3 directories are not listed because either applying the XDG base directory specification to them does not make any sense, or because we need to put application data at least somewhere:

• .local: Contains all the application files, neatly organised and inspired by the Linux FHS
• .pam_environment: Bootstrap ("chicken-or-egg") issue, as it is the very first thing that sets environment variables, at login (some people are trying it nevertheless: [1])
• .ssh: Bootstrap ("chicken-or-egg") issue, because it is the very first thing that is checked for SSH logins (i.e. before a login even happens) (some people are trying it nevertheless: [2])

Currently, the colour scheme is baked into the vimrc itself, rather than defined in a separate file. Also, there is quite a lot of stuff in there that should be rearranged, or better just removed.

In .xinitrc, we set the keyboard layout to the installed ayekat layout. However, on phobia (my stationary machine), I end up with an en_US layout and have to manually setxkbmap the right layout.

Need to check why the layout is not properly loaded on phobia (but is on chirschi).

The dotfiles repository has become rather large, and it would make sense to add some sort of automation for installing and managing the symlinks. This may range from simple install scripts to elaborate control scripts (dotctl comes to mind 😃).

Hey,

Thanks for the inspiration to continue on this task to clean out my home and structure my configs.

I was wondering if it makes sense to put all the parts of your repo that bend programs to adhere to the xdg specific or to be exact this ~/.local structure.
Your approach is quite similar to the emacs-package no-littering.
Maybe something like xdg-no-littering would be nice.

This way your approach can be reused by a wider base of users.

Currently we use a somewhat badly written helper script for running dispwin to set an ICC profile for the screens, depending on the hostname (not things like the monitor EDID or other things, see also issue #1).

There appears to be xiccd, which we can use to interact with colord and set colour profiles through that. It's probably worth taking a look at.

$ qutebrowser -r
/home/ayekat/.local/lib/dotfiles/bin/qutebrowser: 41: shift: can't shift that many

A more meaningful error message would be nice here.

I noticed you use some Qt/KDE apps, this might help you to keep track:
https://bugs.kde.org/show_bug.cgi?id=397602

The pulseaudio-tcp.service user service (for listening to MPD as my secondary user) doesn't load the module-native-protocol-tcp PA module at initial startup (or it gets unloaded by some later action by either PA itself or the user service).

A subsequent systemctl --user restart pulseaudio-tcp.service solves the issue, but that's not very convenient.

Find out what causes the module to be unloaded or not loaded in the first place.

See https://gitlab.com/ayekat/karuiwm/-/merge_requests/14.

Before that one gets merged, packaged, and installed on my workstations, we should translate the current configuration from karuiwm-git into a .kwm script.

Make it use the monitor's EDID to determine which colour profile to apply. The EDID can be seen with xrandr --prop. Perhaps there is a way to easily obtain that value.

The XDG base directory specification does not specify where user-specific variable program data goes. Also, we're already replicating to some extent the FHS under ~/.local (we've already got bin, src and opt), so the logical next step would be the following transitions:

• ~/.config → ~/.local/etc
• ~/.cache → ~/.local/var/cache and ~/.local/var/log
• ~/.local/share → ~/.local/share and ~/.local/var/lib (split variable data)

To avoid spreading non-conforming applications' data (a.k.a. probably all applications' data) over multiple places, sym-linking the old directories to the new ones might be a good idea.

It appears that the mutt documentation now refers to pgp_default_key rather than pgp_self_encrypt_as, so I'm not sure if it was deprecated or simply replaced (and thus my self-encryption mechanism no longer works).

Should check and potentially update my muttrc.

I frequently attach and detach screens, and it would be nice if there was a way to automatically configure the external screen (at least in known cases/for known screens).

https://tyler.vc/auto-monitor-detection-on-linux describes how to tap into udev for detecting screen (un)plug events. Although I would certainly implement my handler differently (permission and environment handling), I think it's worth trying out something similar there (though potentially that will mostly happen in a dedicated tool, i.e. not in this dotfiles repo).

But the basics are there.

Hello @ayekat

What happened to karuibar ?

Can you give me a tarball with all commits and the program itself ?

Regards,

su8

I am aware I am entering war territory here. But this is my personal configuration, and this is the way I prefer it: I use one space after a period at the end of a phrase, and I would like vim to respect that when auto-formatting a paragraph with gqap.

Currently, there are a few configuration files and shell snippets that assume that the dotfiles repository has been cloned into $XDG_LIB_HOME/dotfiles. Allowing the repo to reside anywhere else would add flexibility to the user (especially when tinkering around in the dotfiles repo itself).

File: etc/sh/config

Currently, we scrap the output of git status --porcelain to obtain informations about the status of the git repository to display in the shell prompt. However, the amount of information we can get from git status --porcelain is rather limited.

As pointed out by @grawity here, we could check the files in the .git directory to extract more (and more precise) informations.

Furthermore, we currently have only two variables to hold the information about the git repository: the branch name and the repository status. Latter has to hold all sorts of states: dirty worktree → all files stages → commited but ahead of remote → clean; but also "special" states like merging, rebasing etc. All of this should be split up into at least one more variable.

Some applications/tools I develop are in dev (not in this repository), others in .local/src, and again others directly in .local/bin. There is no real reason for the separation. But the dotfiles repo isn't the place for putting shell scripts and tools either.

For some reason, Debian does not set the the PAM_ITEM @{HOME} (or for some reason, Arch does set @{HOME}), which breaks the setup on Debian.

I need to investivate which component in the login procedure (I suspend systemd-logind) is responsible for setting that variable, and how exactly logind, PAM, and pam_env.so interact with each other.

When following a URL hint in zathura, the link gets opened in both qutebrowser and Firefox.

I have attempted to remove the x-scheme-handler/... associations from firefox.desktop (see e8ea6a0), but this doesn't change anything.

As I have not experienced this issue with any other software, I assume that the issue lies with zathura. But I will need to investigate a little further.

Possible approach

• Install further web browsers and see if they get all opened along with Firefox and qutebrowser.
• Check zathura (e.g. with strace)—also take a look at its source.

Currently, all wrapper scripts assume the executable's "real" location to be /usr/bin.

This assumption fails in the following cases:

• If the system administrator has installed the application to a different place (e.g. /usr/local/bin).
• If the system is not Arch Linux (i.e. /usr/sbin also exists).
• If the system has not undergone the /usr-merge yet (e.g. Debian).

A proposed solution would be to somehow obtain a "list" of valid paths to executables with that name, and strip the wrapper script itself from that list in order to have it execute the next entry in that list. I'm not sure if this is feasible, though.

Currently, applications open text files either with pluma or gvim, which is both not very optimal.

This will most likely require adding .desktop files and MIME type associations for xvim, although latter is not always trivial (see also issue #13).

Currently I expand XDG_DATA_DIRS in .pam_environment as follows:

XDG_DATA_DIRS DEFAULT="/usr/local/share:/usr/share" OVERRIDE="${XDG_DATA_DIRS}"
XDG_DATA_DIRS DEFAULT="${HOME}/.local/share:${XDG_DATA_DIRS}"

This, however, results in ${HOME}/.local/share being prepended 3 times to /usr/local/share:/usr/share. I assume that this is just due to an endless "re-triggering" of assignments, which is aborted by PAM after 3 iterations:

/home/ayekat/.local/share:/home/ayekat/.local/share:/home/ayekat/.local/share:/usr/local/share:/usr/share

See also:

• https://bbs.archlinux.org/viewtopic.php?pid=1717485
• https://www.redhat.com/archives/pam-list/2017-June/msg00000.html
• linux-pam/linux-pam#35

With PAM developers having switched to setting user_readenv to 0 by default recently, and now with them voicing their intent to remove ~/.pam_environment entirely, it's a good moment to seriously start thinking about moving variable declaration to environment.d.

The downsides are:

• environment.d reads from $XDG_CONFIG_HOME/environment.d, so there is a bit of a bootstrapping issue here: with pam_env disappearing, one can no longer define $XDG_CONFIG_HOME before environment.d runs (so it will either default to the specification-defined default (~/.config), or whatever the local sysadmin decides to set system-wide). We'll need a not-too-painful way of adapting to the individual cases; probably by symlinking ~/system-specific-xdg_config_home/environment.d to ~/.local/etc/environment.d as part of the initial dotfiles setup.
• environment.d only applies to the systemd user daemon, but not the user session. So we will need a way to import variables into the login session as well. Either by evaling the output of systemctl show-environment, or by reading the environment.d files directly (given that the show-environment output isn't POSIX conform, so we can't put that in etc/sh/profile.d).

It's less than ideal, but as far as I can see, it's the only thing that is currently left for setting environment variables.

The XDG base directory specification defines XDG_DATA_HOME as a place where "user specific data files should be stored". This description is obviously a bit vague, and it fails to properly distinguish between static/immutable data (equivalent of /usr/share or /usr/lib) and mutable data for state information (equivalent of /var/lib), and has now led to this issue.

I have observed that the majority of application appear to treat it as the latter, and store mostly state/mutable data into XDG_DATA_HOME. There are a few exceptions to this, though (e.g. applications or icons, whose FHS equivalent would probably be in /usr/share), so really it's a mix of two different things.

Since I'm already in the business of extending the severely lacking XDG basedir spec with custom variables (think XDG_LOG_HOME and XDG_LIB_HOME), the proposal is thus now to add another new variable intended to properly split up these two things. The two options are:

XDG_???_HOME for immutable/static data, XDG_DATA_HOME for mutable/state data

This is the way I've treated it so far (it points to ~/.local/var/lib), and it appears to be the way most applications use it for (which is understandable, because static data is rarely generated at runtime, and is usually already present system-wide, i.e. /usr/share and /usr/lib).

If we keep it this way, we'd need to introduce a new variable name (can't think of any right now) and have it point to ~/.local/share.

XDG_DATA_HOME for immutable/static data, XDG_STATE_HOME for mutable/state data

This would be the opposite approach, and we'd need to introduce a new variable for the state information. This seems more consistent for various reasons:

• XDG_DATA_DIRS is the equivalent for all static data directories (defaulting to /usr/local/share:/usr/share), so reusing DATA as the static equivalent under the users' home directories seems sensible.
• There have been multiple proposals and custom extensions in the past for mutable/state data, usually labeled XDG_STATE_HOME, so we'd already have a commonly accepted name.
• I expect it to be easier to move applications to storing their data (mutable) in a different location than to move applications to expect existing data (immutable) in a different location. Putting the base data directory in ~/.local/share and then telling applications to store their state in ~/.local/var/lib seems thus a viable strategy.

Yes, you may notice that I'm in favour for the second option :-)

Links

• https://wiki.debian.org/XDGBaseDirectorySpecification#Proposal:_STATE_directory
• https://lists.freedesktop.org/pipermail/xdg/2009-February/010191.html
• https://lists.freedesktop.org/pipermail/xdg/2012-December/012598.html
• https://lists.freedesktop.org/archives/xdg/2016-December/013803.html
• ActiveState/appdirs@ea0701d
• … and more! (search the web for XDG_STATE_HOME)

Right now I'm looking at 49 qutebrowser sessions, of which I maybe use 3 or 4 regularly, and probably 10 in total. The rest are either obsolete, or just due to typos.

Maybe the acts of creating and restoring sessions should be split; in particular, restoring a non-existing session should not be possible. This would prevent typos (which probably account for about 30% of all the sessions).

Also (or alternatively) having an elegant way to list and delete existing sessions would be nice, too.