Entries tagged 'bash-preexec'

As I mentioned, one of the reasons I was trying to get organized in setting up my development environment under chezmoi was because I was wanted to start using Atuin, which does what it claims in making the shell magical. It stores and syncs the shell history (in an SQLite database behind-the-scenes), and while I have only just started using it, it seems pretty great. Before starting with it, I just had the bash history set up on my primary development machine to never expire, so there was six years of history there (now imported into Atuin).

But Atuin is fairly new, and I ran into some rough edges. One is that because I’m still using the bundled bash on macOS, and it is a very old version of bash, not everything works correctly (accessing the history by up-arrow just errors out). This has been fixed in the Atuin repo, so it should no longer be a problem after they roll out their next release.

As I finished integrating Atuin into my chezmoi setup, I noticed that it seemed to no longer be updating the history on my Linux box. When I went into debugging it, I finally found that I was loading two different versions of bash-preexec. One was being loaded by my chezmoi setup (where it is set up to download to ~/.bash-preexec.sh in my .chezmoiexternal.toml), and the other was being loaded by /etc/profile.d/wezterm. My version was 0.5.0, the version that WezTerm was loading was 0.4.1.

Between those two versions, bash-preexec decided to change the variable that they use to prevent double-inclusion, but the implementation was sort of one-way: the new version would set both the old and new variables, but only check the new one. So if you loaded the old one first, the new one would still load and (apparently) not work correctly.

I let Wez know that he was bundling an old version, which he promptly updated (and so it’s fixed in the nightly builds now). I also submitted a patch to bash-preexec to pay attention to the old guard variable, so whenever they do a new release that particular problem won’t bite anyone else. (They will face a new one, where having an old version of bash-preexec loaded may prevent the newer version from loading, but that should be relatively straightforward to figure out.)

This journey brought to mind an experience I had at HomePage.com about 25 years ago. We had a fleet of front-end web servers that all accessed user storage on an NFS server (an F5 box) and we were running into trouble where the Linux machines would periodically get stuck or die. It was an all-hands-on-deck situation trying to figure it out, and I eventually hit enough things with hammers to figure out that it was a bug in Linux NFS and there was a fix in a later kernel version that I could just back port and suddenly our Linux machines were stable. I pointed out the fix that could be back ported to Alan Cox, then maintainer of the stable Linux kernel. It’s possible they were pulling my leg about it, but the marketing/PR people at the company talked about putting out a press release about how I had fixed a bug in NFS on Linux. I found the whole idea embarrassing and felt this was all just part of the normal open source process.

(Small side note: The company ended up migrating the front-end servers to FreeBSD, which had been a parallel investigation to me debugging the NFS problem.)

This is the sort of mess I enjoy digging my way out of, and it is generally more fun to do this in the open source world than in some company’s proprietary codebase.

Another tool I plan to explore is ble.sh which is recommended by Atuin. The entire idea of line-editing and syntax highlighting built entirely in shell code sounds ludicrous.