thomas.koppandClaude Opus 5
ce560c315d
Load order is the substance of this change, and two attempts got it wrong in
the same way. oh-my-zsh consumes both the plugins array and the theme while it
is being sourced, so anything set afterwards is silently ignored. The plan had
plugins in the stub but the theme in the role file, which produced a shell
reporting ZSH_THEME=powerlevel10k while running without powerlevel10k at all -
132 of its functions missing and nobody any the wiser. Plugins and prompt are
now both resolved before oh-my-zsh, the latter in 05-prompt.zsh.
Portability is handled by asking whether a command exists rather than by
duplicating files per role. "alias ls='lsd'" turns ls into a broken command on
a machine without lsd, and the Mac is such a machine; the yay aliases and
helpers are gated the same way. That keeps one shared base instead of three
diverging copies.
The plan also guessed the plugin list as (git fzf). It is actually seven
entries, so five would have vanished - among them signal-keyring, which turned
out to be a local custom plugin present on this machine only. Naming it
elsewhere means an oh-my-zsh warning at every login, and its content is a
verbatim copy of the gnome-keyring block already in .zshrc, so it ran twice.
The inline block stays, in the desktop role; the plugin is dropped.
Dead code removed rather than carried over:
- PYTHONPATH pointed at /usr/lib/python3.9/site-packages. Python here is
3.14 and that directory does not exist.
- XDG_SESSION_TYPE was forced to x11 and then tested for "wayland" six lines
below, so that branch could never be taken. The variable belongs to the
session; overriding it lies to everything that reads it.
- drm() was defined twice, the first losing to the second on every start.
- PATH carried ~/bin, ~/.scripts and /usr/X11R6/bin, none of which exist.
Entries are added only if the directory is there.
Verified against the live configuration in an isolated ZDOTDIR: 277 aliases and
263 functions on both sides, none missing, and powerlevel10k loading for all
three roles with the intended colour.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
DISCLAIMER:
this is not my work I've the idea from https://developer.atlassian.com/blog/2016/02/best-way-to-store-dotfiles-git-bare-repo/
In his words the technique below requires:
No extra tooling, no symlinks, files are tracked on a version control system, you can use different branches for different computers, you can replicate you configuration easily on new installation.
but for reason: ;)
- git and
- curl
How it work
The technique consists in storing a Git repository in a "side" folder (like $HOME/.cfg or $HOME/.myconfig) using a specially crafted alias so that commands are run against that repository and not the usual .git local folder, which would interfere with any other Git repositories around. Starting from scratch
If you haven't been tracking your configurations in a Git repository before, you can start using this technique easily with these lines:
git init --bare $HOME/.cfg
alias config='/usr/bin/git --git-dir=$HOME/.cfg/ --work-tree=$HOME'
config config --local status.showUntrackedFiles no
echo "alias config='/usr/bin/git --git-dir=$HOME/.cfg/ --work-tree=$HOME'" >> $HOME/.bashrc
The first line creates a folder ~/.cfg which is a Git bare repository that will track our files. Then we create an alias config which we will use instead of the regular git when we want to interact with our configuration repository. We set a flag - local to the repository - to hide files we are not explicitly tracking yet. This is so that when you type config status and other commands later, files you are not interested in tracking will not show up as untracked. Also you can add the alias definition by hand to your .bashrc or .zshrc or use the the fourth line provided for convenience.
I packaged the above lines into a snippet up. So that you can set things up with:
curl -Lks https://ls.shron.de/dotconf | /bin/bash
After you've executed the setup, any file within the $HOME folder can be versioned with normal commands, replacing git with your newly created config alias, like:
config remote add dotconfs url.to.remote.repo
config checkout
config status
config add .vimrc
config commit -m "Add vimrc"
config add .bashrc
config commit -m "Add bashrc"
config push
Install your dotfiles onto a new system (or migrate to this setup)
config pull