dotfiles

Configuration files for my Linux systems

Intro

Hi!
Welcome to the davla's configuration files repository, aka "dotfiles".
The configuration is used on three systems: my personal laptop, running sway on Arch Linux; my Raspberry Pi,
running headless Arch Linux ARM; my work laptop, running i3 on Debian.
The system provisioning is handled in bot.sh, which leverages dotdrop to copy configuration files around on
the filesystem.
Dotdrop is executed as a Python dependency via uv. The Python version is pinned by asdf.
Some configuration files contain sensitive information, especially for my work laptop configuration. They are
encrypted in this repository via git-secret.

Dotdrop

README

Dotdrop constitutes the functioning core of this repository. Immense gratitude to deadc0de6 for creating and
maintaining such an amazingly useful tool!
The whole dotdrop setup is located at dotfiles. Dotdrop is so central to this repository that it has its own
documentation section in dotfiles/README.md.

bot.sh

The bot.sh script is where you will see these faces!
The script is meant as the entry point for the whole system provisioning. Therefore it is written in POSIX shell
and it assumes that only the basic tools are already installed on the system. Or at least, that would be my
goal. Anything else needed is installed by the script itself, from the Python interpreter to dotdrop.
The core of the script consists in going through a series of steps, asking before each whether to execute or
skip it. Additionally, you can execute a specific step by name, either by passing it on the command line, or by
interactively entering it when prompted.
There is no information on which steps should be run on which host. I also get it wrong often.
Each step runs in a terminal alternate buffer (if supported) for a cleaner output. The output is also written to
a log file that can be inspected after the step execution. The log file is deleted before proceeding to the next
step.
Reading the log file needs to happen in another terminal for the time being. You also need to stay on the step
you want to read the logs for in the terminal running the bot script, otherwise the log file is deleted.
After executing each step, the bot will ask you if you want to try to execute the step again, or proceed to the
next step. This is meant as a form of debugging, as you can edit the step code in case of errors and try again
right away.
There is an annoyingly large overlap between the bot steps and dotdrop actions. The overall criterion to
determine where the setup code should be placed is "dotdrop actions contain code that is needed for the
configuration files not to crash, while bot steps contain code that is needed for the configuration files to be
used". This is admittedly not a very good and clean-cut criterion, and likely means that I should just stick to
one place for the setup code.

Desired improvements

Make opening bot step log files more convenient. Possibly via a dedicated answer after step execution.
Stop using LightDM.
Actually send myself a mail on at job errors.
Move shell functions and aliases to separate executables.
Refresh shell completions/cache as hooks for plugin/package updates.
Add dotdrop, sheldon and more shell autocompletion.
Setup keyboard shortcuts for bluez.
Prevent dotnet crypto stuff from showing up in $HOME.
Allow logger colors with no tags.
Investigate more uses for jinja default.
Investigate uses of empty dst: instead of mktemp.
Update append dotdrop action so that it doesn't remove.
Don't use STDERR in aesthetics.sh::get_archive to prompt the user.
Ensure systemd daemon-reload before enabling in pacman hooks.
Ensure that autorandr environemnt variable are loaded in xsessionrc.
Handle failure with pkgfile database update at Arch startup.
Better placement of logger_path dotdrop variable.
Automatically update ACYLS icons.
Fix problems with mako actions.
Update bot relative paths.