A rabbit hole of new Linux shell stuff

 I have installed k3s to a machine, trying to experiment with Kubernetes in a small scale.

As one of the options that I can run in the (currently single-node) cluster was atuin (https://atuin.sh/) It's an optionally self-hosted shell history search & sync tool. It's like fzf for searching, but for sync I didn't know of anything like it. As shell history is a bit... sensitive, self-hosting the sync server sounded like a good first pod for my budding Kubernetes cluster.

It's not a bad experience, and it worked, I mostly used official docs in https://docs.atuin.sh/self-hosting/kubernetes/ with little tweaks.

The rabbit hole started from the installation of the command line tool. Installing the shell plugin doc asks you to either use ble.sh (not a URL, home page at https://github.com/akinomyoga/ble.sh) or bash-preexec. The latter is discouraged so I went with the first. This step of the rabbit hole already blew my mind, I found a lot of user-friendly features from zsh and fish already built and enabled by default for bash.

I had been using bash due to inertia — a lot of scripts collected over the years, and muscle memory— although I was aware of newer options like fish, nu shell, and elvish but never had extensive time to start building muscle memory for them and porting the scripts I had. ble.sh gives context-sensitive completions which are really useful, as well as syntax highlighting and the highlighting of errors (like missing closing parenthesis or quotes). The error highlighting has already proven worthwhile in the hours I've installed ble.sh

Also, in the installation and setup section for Atuin shell plugin, I see a section for a shell called Xonsh (https://xon.sh) This was news to me, it's a python powered shell and allows you to mix shell in python, or python in shell. Noted this down aside as the rabbit hole went deeper.

In the xonsh contrib section there was a link to https://carapace.sh/, a "A multi-shell completion library". I was a bit puzzled; shells have their own completion why would I want a probably slower cross-shell library? The screencasts in the carapace website also kept blewing my mind (there is little of it left after all this shell goodness maelstrom extravaganza). The vaguely named "Embed continuously" stream shows carapace detecting subcommands inside subcommands and correctly completing the relevant level of command.

The last bit of the rabbit hole that I'll talk about is gum (https://github.com/charmbracelet/gum) it's more of a rediscovery than a brand new discovery as I was aware of the existence of  charm bracelet tools, but never had a chance to use it. This reminds me of Chris Krycho's post on scripting. Even though the focus of that article is writing little scripts in Rust, I'm more focused on writing little scripts, instead of making notes of a multi-stage, relatively simple process and trying to find the notes later. Or bookmarking a tool that might be useful for a specific use case, but then forgetting the name and the existence of the tool, I can write a script in my ~/.bin/ with a name of the use case, executing the tool. Even though the script may be a barebones wrapper, it'll live in my version controlled and synced .bin directory, and it'll be easier for me remember or rediscover that. And it allows to build on the script to add more features as needed, while documented list of commands quickly grows to unmanageable sizes. I think fasterthanli.me had a post in the same vein. Gum will help in this endeavour by making the process of writing the scripts and using them fun and interactive.