Forrest Jacobs

Shell-agnostic config

Fri, 29 Aug 2025 20:42:00 -0400

I love fish, and I have built up my fish config over time:

~/.config/fish/config.fish

# Set helix as the editor if it's available.
if type -q hx
 set -gx EDITOR hx
end

set -gx MANOPT --no-justification # Badly justified text is terrible

abbr S 'sudo systemctl'

# etc...

I’ve started working in environments where it’s infeasible to switch the shell from bash, but I still want to use my config. I could make a parallel .bashrc with the equivalent commands, but that’s bound to get out of date. Instead, I turned my fish config into a bash script that prints out the correct instructions for either bash or fish (a la brew shellenv [shell] or zoxide init [shell]). It looks like this:

init_shell.sh

#!/usr/bin/env bash

# init_shell: Prints instructions to configure the given shell.
# Add `eval "$(init_shell bash)"` to .bashrc to set up bash
# or `init_shell fish | source` to config.fish to set up fish.

shell=$1

# Escapes and prints the passed in string.
escape () {
 local text=$1
 text=${text//\\/\\\\}
 text=${text//\'/\\\'}
 echo "'$text'"
}

# Prints a command that sets an environment variable in $shell.
# Pass in the variable name, then the value.
p_export () {
 export "$1"="$2"
 if [[ "${shell}" = "fish" ]]; then
 echo "set -xg $(escape "$1") $(escape "$2")"
 else
 echo "export $(escape "$1")=$(escape "$2")"
 fi
}

# Prints a command that sets an abbreviation in $shell.
# Pass in the abbreviation name, then the full command.
p_abbr () {
 if [[ "${shell}" = "fish" ]]; then
 echo "abbr $(escape "$1") $(escape "$2")"
 else
 echo "alias $(escape "$1")=$(escape "$2")"
 fi
}

# Set helix as the editor if it's available.
if command -v hx &> /dev/null; then
 p_export EDITOR hx
fi

p_export MANOPT --no-justification # Badly justified text is terrible

p_abbr S 'sudo systemctl'

# etc...

Admittedly, this design introduces quite a bit of complexity. For example, you’ll notice the p_export function exports the environment variable in the script before printing out the export command. This is to ensure that later commands in this script can access the environment variable the same way the shell would. You can imagine how easily the command’s internal state could drift from the shell’s state in subtle, difficult to debug ways.

But this additional complexity is worth it for me. My other options are to abandon or duplicate my config (yuck), or switch to bash everywhere (double-yuck). This design has been working well for me for a few weeks.

Rust to Go and back

Mon, 19 May 2025 13:11:00 -0400

I wrote two Discord bots relatively recently: a bot called systemctl-bot that lets you start and stop systemd units, and a bot called pipe-bot that posts piped messages. I attempted to write both in Rust, and while one was a delight to write, the other I ended up rewriting in Go in a fit of frustration. Here are a few reasons why:

Starting off too complex

pipe-bot, the program I successfully wrote in Rust, is very simple — it listens to standard in, then calls to the Discord API based on the message:

A diagram showing the flow of execution for pipe-bot. After starting a Discord client, it waits for stdin, parses it, and then either sends a message, updates the Discord status, or logs an error based on the parsed message.

However, I started with systemctl-bot, which monitors and controls systemd units, parses and shares a config file, reads async streams, and generally has weird edge cases. While it’s not overly complex, it’s a lot to get your head around when you’re also learning the borrower checker and async Rust.

A diagram showing the more complex flow of execution for systemctl-bot. It parses a config file, starts a Discord client, and then branches off into two threads: one handling status updates, and the other handling commands (after registering them with the Discord client.) The status thread waits for unit status updates, then fetches all units' statuses and updates Discord. The command loop waits for a user command, calls systemctl with the appropriate arguments (provided that the targeted unit is in the config file) and then posts the results. If the unit was not in the config file it logs an error instead.

Async Rust

I anticipated fighting with the borrower checker, but—oh boy!—it pales in comparison to writing and understanding async Rust. Since I was coming from the world of “””enterprise software”””, I was used to writing with a level of indirection to facilitate code reuse, unit testing, and refactoring. However, Rust makes you pay for indirection that involves tracking more state or more complex state since it has to track that state while the async call is in progress. Watch this video to hear someone much smarter than me explain why the current state of async Rust ain’t quite it yet:

Catching up with async Rust by fasterthanlime on YouTube

Testing

Something possessed me to go full enterprise software sicko mode during the development of systemctl-bot and unit test every module to as close to 100% coverage as possible. I’m glad I did because it taught me more about generics and about Box, Rc, and Arc as I tried to find ways to mock dependencies, but it also taught me that this style of testing in Rust produces a huge glob of code that is painful to wrangle.

I decided to take a different approach while developing pipe-bot: I just mocked the outer edges of my program and let every test be an integration test. Any unit-level errors that mattered seem to come up in these tests, and since my program was small it wasn’t difficult to identify the specific function where the error originated. I got 99% of the benefit of unit testing with 20% of the effort.

Final thoughts

I enjoy Rust, but I respect Go. Rust is more fun to write, and the compiler’s strict checking is a superpower that ensures you don’t screw yourself up too badly. However, async Rust is a huge pain for me, and while Go is boring, sometimes it’s the ticket to complete a project.

Keeping NixOS systems up to date with GitHub Actions

Tue, 03 Sep 2024 12:00:00 -0400

Keeping my NixOS servers up to date was dead simple before I switched to flakes – I enabled system.autoUpgrade, and I was good to go. Trying the same with a shared flakes-based config introduced a few problems:

I configured autoUpgrade to commit flake lock changes, but it ran as root. This created file permission issues since my user owned my NixOS config.
Even when committing worked, each machine piled up slightly different commits waiting for me to upstream.

I could have fixed issue #1 by changing the owner, but fixing #2 required me to rethink the process. Instead of having each individual machine update their lock file, I realized it would be cleaner to update the lock file upstream first, and then rebuild each server from upstream. Updating the lock file first ensures there’s only one version of history, and that makes it easier to reason about what is installed on each server.

Below is one method of updating the shared lock file before updating each server:

Updating flake.lock with GitHub Actions

The update-flake-lock GitHub Action updates your project’s flake lock file on a schedule. It essentially runs nix flake update --commit-lock-file and then opens a pull request. Add it to your NixOS config repository like this:

/.github/workflows/main.yml

name: update-dependencies
on:
 workflow_dispatch: # allows manual triggering
 schedule:
 - cron: '0 6 * * *' # daily at 1 am EST/2 am EDT

jobs:
 update-dependencies:
 runs-on: ubuntu-latest
 steps:
 - uses: actions/checkout@v4
 - uses: DeterminateSystems/nix-installer-action@v12
 - id: update
 uses: DeterminateSystems/update-flake-lock@v23

Add this step if you want to automatically merge the pull request:

 - name: Merge
 run:
 gh pr merge --auto "${{ steps.update.outputs.pull-request-number }}" --rebase
 env:
 GITHUB_TOKEN: ${{secrets.GITHUB_TOKEN}}
 if: ${{ steps.update.outputs.pull-request-number != '' }}

Pulling changes & rebuilding

Next, it’s time to configure NixOS to pull changes and rebuild. The configuration below adds two systemd services:

pull-updates pulls config changes from upstream daily at 4:40. It has a few guardrails: it ensures the local repository is on the main branch, and it only permits fast-forward merges. You’ll want to set serviceConfig.User to the user owning the repository. If it succeeds, it kicks off rebuild…
rebuild rebuilds and switches to the new configuration, and reboots if required. It’s a simplified version of autoUpgrade’s script.

NixOS Config

systemd.services.pull-updates = {
 description = "Pulls changes to system config";
 restartIfChanged = false;
 onSuccess = [ "rebuild.service" ];
 startAt = "04:40";
 path = [pkgs.git pkgs.openssh];
 script = ''
 test "$(git branch --show-current)" = "main"
 git pull --ff-only
 '';
 serviceConfig = {
 WorkingDirectory = "/etc/nixos";
 User = "user-that-owns-the-repo";
 Type = "oneshot";
 };
};

systemd.services.rebuild = {
 description = "Rebuilds and activates system config";
 restartIfChanged = false;
 path = [pkgs.nixos-rebuild pkgs.systemd];
 script = ''
 nixos-rebuild boot
 booted="$(readlink /run/booted-system/{initrd,kernel,kernel-modules})"
 built="$(readlink /nix/var/nix/profiles/system/{initrd,kernel,kernel-modules})"

 if [ "''${booted}" = "''${built}" ]; then
 nixos-rebuild switch
 else
 reboot now
 fi
 '';
 serviceConfig.Type = "oneshot";
};

There are many possible variations. For example, in my real config I split the pull service into separate fetch and merge services so I can fetch more frequently. You could also replace the GitHub action with a different scheduled script, or change the rebuild service to never (or always!) reboot.

Waiting on Tailscale

Tue, 27 Aug 2024 12:00:00 -0400

I restarted my server the other day, and I realized one of my systemd services failed to start on boot because the Tailscale IP address was not assignable:

# journalctl -u bad-bad-not-good.service
...
listen tcp 100.11.22.33:8080: bind: cannot assign requested address

This is easy enough to fix. The service should wait to start until after Tailscale is online, so let’s just add tailscaled.service to the the service’s wants and after properties, reboot, and…

# journalctl -u bad-bad-not-good.service
...
listen tcp 100.11.22.33:8080: bind: cannot assign requested address

Huh. It turns out Tailscale comes up a bit before its IP address is available. I was tempted to add an ExecStartPre to my service to sleep for 1 second – gross! – but eventually I found systemd’s fabulous systemd-networkd-wait-online command, which exits when a given interface has an IP address. Call it with -i [interface name] and either -4 or -6 to wait for an IPv4 or IPv6 address.

Wrapping it up into a service gives you something like this:

tailscale-online.service

[Unit]
Description=Wait for Tailscale to have an IPv4 address
Requisite=systemd-networkd.service
After=systemd-networkd.service
Conflicts=shutdown.target

[Service]
ExecStart=/usr/lib/systemd/systemd-networkd-wait-online -i tailscale0 -4
RemainAfterExit=true
Type=oneshot

Services using your Tailscale IP address can now depend on tailscale-online.

Using Syncthing to sync coding projects

Sat, 06 May 2023 12:00:00 -0400

I code on a MacBook and a Windows PC, and I want to keep my coding projects in sync between them. Here are my wishes in decreasing priority:

Code changes on my MacBook should magically update my PC, and vice versa. (Think Dropbox.)
Some files should not sync, like host-specific dependencies and targets. I want to ignore these files via patterns, a la gitignore.
Ideally, this sync extends to both a headless Linux server I use for remote development, and to WSL on my Windows PC.

After experimenting with other solutions (outlined below) I discovered that Syncthing meets every requirement.

What I tried first

1. OneDrive

I use OneDrive to sync most of my files. It’d be nice to just add my coding projects to OneDrive, but it doesn’t work in practice: ignoring files is awkward, and seemingly only works on Windows. Additionally, OneDrive doesn’t run on Linux without some help.

Dropbox looks like a better fit on paper: it can ignore files on any platform (in a different, awkward way) and it has a first party Linux client. But switching to Dropbox would be painful – my partner and I switched away from Dropbox about a year ago because we were getting more storage for less money from Microsoft, and the modern Dropbox app sucks.

2. Remote development

If the issue is syncing files across computers, why don’t I just work on one computer? Well, developing on a remote machine has its own issues:

Blips in internet connectivity become big problems. At best, you wait for keystrokes to appear over SSH. At worst, you can’t code at all. (And while file sync also requires connectivity, a few seconds is enough to sync changes.)
Waiting for my dinky free-tier Oracle Cloud VM to compile a complex Rust project is frustrating. Sure, I could rent a better VM, but it’s silly to pay for that additional power when I have a more than capable computer in front of me.
Some development doesn’t work well in a remote environment. Web dev is fine, but what if I want to play around with game or mobile dev?

3. Git

Can’t I just use Git to stay up to date?

No – version control is different than file sync. I don’t want to track personal config files in version control, but I do want to sync them. And I don’t always want to check in work in progress – for example, I don’t want to check in changes that cause builds or tests to fail.

Using Syncthing

Syncthing is amazing. It does everything I outlined at the top – it syncs my projects, it ignores files based on patterns, and it runs everywhere I code (Windows, MacOS, and Linux.)

I resisted using it because of its high barrier to entry. It uses peer-to-peer file syncing, so you need to set it up on a server to ensure each computer sees the latest changes. And its configuration is more involved than something like Dropbox.

But it’s still worth it for me because it solves all my original problems. (And I want to sync these files to a server anyway.) If you’re struggling with the same issues I ran into, and you’re willing to set up a server, give Syncthing a shot.

Addendum: Syncing your ignore patterns

Syncthing does not keep your ignore patterns in sync across hosts, but there’s a way around it:

Create a text file with the patterns you want to ignore.
Save it to your Syncthing folder.
Add #include name-of-that-file to each host’s ignore patterns.

Voilà!

NixOS on WSL

Sun, 22 Jan 2023 12:00:00 -0500

I recently set up a new Windows machine for gaming, but I’m actually using it more to play around with Linux via WSL. I set up NixOS on WSL using the aptly named NixOS on WSL project, but ran into a few issues during setup that bricked my environment¹. Below are the steps that ended up working for me in the end:

Goals

Set up NixOS in WSL 2 on a new Windows 11 install (version 22H2.)
Reuse my flake-based configuration from my other NixOS 22.11 installations.
Take advantage of native systemd support in WSL.

Step 1: Install WSL 2

Per Microsoft’s documentation:

Open PowerShell as an admin by right-clicking on it and selecting “Run as administrator.”
Run wsl --install

Step 2: Install NixOS

Per NixOS-WSL’s documentation:

Download the installer listed in NixOS-WSL’s 22.05 release.
Move the file where you want your NixOS installation to live. I put it in C:\Users\<my username>\AppData\Local\NixOS, which I think follows Windows’s conventions.
Open PowerShell as a normal user, change to the directory you just made, and run wsl --import NixOS . nixos-wsl-installer.tar.gz --version 2
Run wsl -d NixOS to start NixOS. It’ll run through initial setup, then hang on “Starting systemd…” Press Ctrl + C to get back to PowerShell, and then run wsl --shutdown followed by wsl -d NixOS to get back into NixOS.

Step 3: Configure NixOS

At this point you should have a basic NixOS 22.05 installation! Let’s finish up by setting a username, switching over to flakes, updating to NixOS 22.11, and enabling native systemd:

Edit /etc/nixos/configuration.nix and make the following changes. Use sudo or some such to edit the file as root. You may want to nix-shell -p your favorite editor at this point – maybe Helix?
- Change wsl.defaultUser to your desired username, and add something like users.users.<your username>.isNormalUser = true;
- Remove references to ./nixos-wsl since we’ll set NixOS-WSL as a flake input:
  /etc/nixos/configuration.nix
```
 { lib, pkgs, config, modulesPath, ... }:
-
- with lib;
- let
- nixos-wsl = import ./nixos-wsl;
- in
 {
 imports = [
 "${modulesPath}/profiles/minimal.nix"
-
- nixos-wsl.nixosModules.wsl
 ];
```
- Add wsl.nativeSystemd = true;
- Add networking.hostName, and set it to your Windows 11 “Device name.” You can find this in the Windows Settings app under System > About.

Add /etc/nixos/flake.nix as root with contents like the following. Replace <host-name> with your actual host name from configuration.nix.

/etc/nixos/flake.nix

{

 inputs = {
 nixpkgs.url = "github:NixOS/nixpkgs/nixos-22.11";
 NixOS-WSL = {
 url = "github:nix-community/NixOS-WSL";
 inputs.nixpkgs.follows = "nixpkgs";
 };
 };

 outputs = { self, nixpkgs, NixOS-WSL }: {
 nixosConfigurations."<host-name>" = nixpkgs.lib.nixosSystem {
 system = "x86_64-linux";
 modules = [
 { nix.registry.nixpkgs.flake = nixpkgs; }
 ./configuration.nix
 NixOS-WSL.nixosModules.wsl
 ];
 };
 };

}

Run sudo nixos-rebuild switch
exit out of NixOS, then run wsl --shutdown followed by wsl -d NixOS. You should be logged in as the new default user.
At this point you should have a stable base to make any configuration changes you’d like.

Step 4: Cleaning up

Rename wsl.automountPath to wsl.wslConf.automount.root in configuration.nix to match NixOS-WSL’s latest configuration.
Delete the now unused /etc/nixos/nixos-wsl directory.
Delete /home/nixos since you’ve changed your username.
You can run sudo nix-channel --remove nixos if you don’t want the channel hanging around now that we’re using flakes.

Addendum: Share `.ssh` directory with Windows

It turns out that file permissions set in WSL are preserved in NTFS². You can store your SSH configuration files in Windows, and still use them from WSL with no permissions issues:

Set up your ~/.ssh in NixOS like normal.
Move your ~/.ssh directory to Windows with mv ~/.ssh /mnt/c/Users/<your Windows username>/.ssh
Soft link it back to your WSL VM with ln -s /mnt/c/Users/<your Windows username>/.ssh/ ~/.ssh

That’s it! You can verify that permissions carried over with ls -al ~/.ssh/

Addendum: Set up fish in NixOS the right way

I use fish as my shell, but when I set it up in WSL I started getting errors like this:

fish: Unknown command: ls
/nix/store/lkf5vmavnxa0s37imb03gv7hs6dh5pll-fish-3.5.1/share/fish/functions/ls.fish (line 64):
 command $__fish_ls_command $__fish_ls_color_opt $opt $argv
 ^
in function 'ls'

Uh oh. Obviously, there are important directories missing from my path. It turns out that I was missing some configuration³: