For moved repositories accessed over http(s), there's 301 Moved Permanently (or Wikipedia), but when accessing using ssh no similar functionality exist on a protocol level. In at least my reality that means redirects work for things where I only have read access, but not for remotes which I also can push commits to. It might be theoretically possible to setup write operations over https, but ssh is much more common.

As already stated, there simply is no way to get a machine readable redirect for git over ssh. The approach here will write a banner to stderr, which ought to be noticable enough for a human git user and hopefully good enough for many cases.

The actual example code will focus on moves to some other directory on the same server, but the same method could be applied to redirect to some completely different server.

When git performs operations through an ssh server, it actually runs a bunch of commands such as git-upload-pack. That is where one can output a redirection message on stderr advising about the new location.

Start by creating /etc/ssh/sshd_config.d/ssh_redir.conf containing something like:

Match User git
    ForceCommand /opt/netizense/libexec/wrapper

Next, the referenced wrapper could look like:

#!/bin/sh
case "$SSH_ORIGINAL_COMMAND" in
  'git-upload-pack '*)
    _our_dir="$( dirname "$0" )"
    PATH="$_our_dir:$PATH"
    export PATH
    # As git-shell ignores $PATH, sh is used here.
    exec /bin/sh -c "$SSH_ORIGINAL_COMMAND"
    ;;
  '')
    exec git-shell
    ;;
  *)
    exec git-shell -c "$SSH_ORIGINAL_COMMAND"
    ;;
esac

In plain language, the script checks whether a specific command is run. If that is the case, it determines its own directory and adds that as the first of $PATH's entries, which enables finding our own version of git-upload-pack when executing that command. All other commands are executed with git-shell as usual. The special handling of the no arguments case is to for interactive shells.

Note that passing arguments to /bin/sh in this manner makes arbitrary command execution possible. I trust all my git users with shell access, so its not a problem on for me. Others might have different policies, thus requiring some adaption to quote shell characters or patching the sources of the actual git-upload-pack executable and recompiling it.

Here follows the script I use for git-upload-pack: (must be in the same directory as wrapper for that $our_dir construct to work)

#!/bin/sh -eu

_git_dir="$( eval echo "\$$#" )"
_real_dir="$( realpath "$_git_dir" )"
[ "$_real_dir" = "$_git_dir" ] || printf '%s\n%s\n\n%s\n\n%s\n%s\n' \
        '******************************************************************' \
        "Please note that $_git_dir has moved to:" \
        "    $_real_dir" \
        'Update your repository remote!' \
        '******************************************************************' \
        >&2
unset _git_dir

exec git-shell -c "$SSH_ORIGINAL_COMMAND"

That script starts with getting the last argument (\$$#) which is directory the git repository is in. It then checks whether it is (within) a symlink or not. In case it is, the warning is printed on stderr. It then launches the original command.

One can of course also add logging or what not to the wrapper script, but I don't personally see a need for that. If doing so, one might want to look at wrapping more (or all) git commands.

In order for these changes to actually bite, sshd needs to be restarted.

Here are mostly merely my notes from a problem I encountered this morning. Not really a proper blog post, but published anyway as I know at least one other person has found it interesting.

Problem description

After upgrading one of my machines from OpenBSD 7.6 to 7.7 I could no longer run (some of) my perl scripts. A trivial hello world script worked, but this extremely stripped down version of an actual script didn't:

#!/usr/bin/env perl

use DateTime;

My expectation of running the above would be that it essentially should do nothing. However what actually happened was that perl returned 1 and gave the following error message as its output:

XS.c: loadable library and perl binaries are mismatched (got first handshake key 0xf280000, needed 0xf180000)

That seems correct, but it is not phrased in a super-helpful way. Given that the script only contains one line, I assumed that the mismatch was between perl and the DateTime module. That one does indeed contain a .so-file which may depend on the perl version. These were both installed the OpenBSD way. As mentioned in the release notes, OpenBSD comes with version 5.40.1 of Perl. On my system DateTime came from package p5-DateTime-1.66v0, installed through ports using pkg_add.

About the error message

Today was not my first time to encounter this error message. I kind of knew what it was all about, on some level. The devil is always in the details, and I have not previously saved any notes. There is an issue, which I have visited in the past and found again today. It is titled "loadable library and perl binaries are mismatched" not informative and is a long-read. It now appears to ended up in better error handling got added as recently as a couple of weeks ago, with the merge of #22719. Great news, for anyone encountering this with a future version of Perl!

Examining my system

When I ran pkg_info -v p5-DateTime-1.66v0 | grep signify it appeared the package (built 2025-04-11T19:55:16Z) was older than OpenBSD 7.7 (released April 28, 2025). I'm not fully understanding the release process though, so it is not impossible the package was built for a release candidate or whatever. When trying to analyze the package on technical merit, I got lost a little. These however seem reasonble to guess having to do with ABI versioning or something:

@wantlib c.100.3 @wantlib perl.25.0

The only file installed by the package which seems to be affected by versions is a shared library. Merely running file on it gave:

/usr/local/libdata/perl5/site_perl/amd64-openbsd/auto/DateTime/DateTime.so: ELF 64-bit LSB shared object, x86-64, version 1

Some comments to the existing bug report suggests examining which perl version the object depends on using ldd. However attempting to do so on OpenBSD, where the command takes no options, only gave:

/usr/local/libdata/perl5/site_perl/amd64-openbsd/auto/DateTime/DateTime.so:
        Start            End              Type  Open Ref GrpRef Name
        00000092cf403000 00000092cf40a000 dlib  1    0   0      /usr/local/libdata/perl5/site_perl/amd64-openbsd/auto/DateTime/DateTime.so

I'm uncertain of how to dig deeper in order to verify it is indeed the culprit. One might suspect that perl is picking up a version of the module installed with cpanm, perhaps? The output of running find "$PERL_LOCAL_LIB_ROOT" -name "*DateTime*" suggest that is not the case though. Maybe the packaged version is actually in a broken state?

Failed mitigation

In an attempt to mitigate the issue, I did pkg_delete p5-DateTime, updated my ports tree and ran make install in devel/p5-DateTime. The error message about versions remained even after doing that, suggesting my hypothesis of the port being to blame was faulty, and the issue to be a bit more complex than what I hoped for.

Successful resolution

After running mv "$PERL_LOCAL_LIB_ROOT" "$PERL_LOCAL_LIB_ROOT-$( date +%Y%m%d )" the issue finally got resolved. In retrospect I should have tried this sooner. Already knowing the DateTime module was not there, one now wonders what the cause could be. Could it be that the DateTime module for some reason was using a locally installed module for something which in some way got installed in some other manner with the OpenBSD upgrade? Analyzing stuff just slightly further, revealed that the failing module was Package::Stash::XS. We recognize XS from the error message. I have not went down the rabbit hole, but it has to do with a foreign function interface for perl. In other words, the issue is not really with the specific module at all. It is rather some kind of problem with module loading in general. Replacing use DateTime; with e.g. use Moose; results in an identical error message.

Summary

What is to learn? Not much which wasn't already known. Installing software should ideally be done using system tools. Using tools like cpanm, cargo, gem, luarocks, pipx, et cetera such should ideally be avoided. Yet as we know, one really can't. So the only real take away for my part is that an eight year old bug, originally reported against 5.24.0, recently got a patch accepted and will likely be in a future release of Perl. Maybe in 5.42.0? I've stopped myself short of trying to understand Perl's release schedule. Fingers crossed, it lands before the release of OpenBSD 7.8.

About a year ago I was given a MacBookPro11,1 (A1502 EMC 2678). This is a mid-2014 model. Its original owner considered it no longer useful to him, as Apple supposedly has dropped support for it in all current macOS releases.

For the first year I ended up using it with FreeBSD while concurrently running alpine linux in a bhyve, because that is how pragmatic problem solving works. This setup broke for me when upgrading to FreeBSD-14.2p3. Or rather, I didn't redo the few required additional steps. I figured the better path surely must be to fully switch to linux. So switched I did.

These are my thoughts from this experience. Please consider most of the text to describe an art project with limitied practical utility. A beautiful thing which will unfortunately never materialize.

Options

While there are literally hundreds of operating systems for intel machines in general, the remaining options drastically reduce when targetting specifically Apple hardware. Many might say macOS, which these computers come with, would be the natural choice. Yet I'm quite sure it is not for me. Apple software is far too opinionated for my taste. Not to mention failing at non-functional aspects such as respecting user privacy and what not. Maybe some versions of Microsoft Windows would run on the machine. I have not investigated that, since it practically becomes uninteresting for the same reasons as macOS. Windows might arguably even be worse than macOS.

With the most limiting factor being wifi, the only remaining kernels to consider are XNU and Linux. That might be a confusing statement, given that macOS was just ruled out as an option for me — Here are rabbit holes to dive down into. What one needs to initially understand is that the contract between Apple and Broadcom appears to have been that the latter license their wifi solution to the former and "take full responsability" from a business perspective. While I don't have actual insight in this, I would say it is fair to assume that only Broadcom has ever had legal access to the wifi driver source code. Neither Apple nor anyone else are likely to ever have had it. Broadcom have compiled and released drivers to platforms of their choice. Contractual obligations and other business reasons has of course influenced their selected platforms to cover the majority of the market. Still, unless one downloads a binary for one of their selected platforms, their wifi interfaces are fully useless.

Drivers for some interfaces have been reverse engineered and I might be sloppy in expressing where the boundaries of firmware and drivers are. Possibly also being technically incorrect about other details, but the main point here is that the laptop model I received fully lacks networking without Broadcom's driver blob.

FreeBSD

As mentioned above in the background section, I did run FreeBSD for about a year. With wifibox(8) providing an alpine based router in a bhyve. Installation is as simple as merely installing the wifibox packages from ports. That setup apparently the only way to the any networking under FreeBSD with these Broadcom BCM4360 (14e4:43a0) equipped laptops. Even though it required running Linux in a virtual machine, wifi actually worked quite well. So did most other things I tried. The internal speakers stayed silent, but sound did work when having headphones connected. As I have a separate dedicated laptop for video conferencing, I never did try the camera nor any other stuff I never needed. The thing which I noticed to not work was suspend/resume. When rebuilding the kernel without SMP I could get to a state where the machine actually woke up, but it was acting all weird after doing so. This lead to me having the laptop turned on for weeks, awake while I was asleep myself. It naturally also limitied the practical portability of the machine. Laptops just are better when suspend and resume are working than when not.

Darwin

Being mostly new to the Apple ecosystem, I assumed it ought to be possible to run some Darwin distribution on this machine. That is however a very faulty assumption. Just to make sure all readers are on track, XNU is the kernel used in Darwin. A detailed understanding can be found by reading the Wikipedia pages linked in the previous sentence, but in summary: OpenDarwin was shut down in 2006 and PureDarwin about a decade later. To the best of my understanding, the only currently alive Darwin derivatives are macOS and its siblings which Apple maintains for their other product lines.

In theory one could probably revive an open source Darwin distribution. It would be a lot of work. Way too much work to be realistic for me to engage in it. But since the "correct" kernel for this hardware is XNU, and that kernel should ideally deserve a life outside of macOS, its a fun thought experiment to entertain for a bit. As none of the open Darwin distributions ever included drivers for the closed broadcom wifi adapters, one may assume that was a huge factor in why the projects failed. When Apple hardware effectively was lacking network, macOS naturally became the only viable option.

If one were to build Darwin this year, to use it on an old macbook, would it be technically feasible to somehow yank the wifi drivers from a macOS installation and shoehorn them into a working state for that system? Unlikely, is my answer. Sure — in the sense that anything is possible, it should be doable. It wouldn't be fun though. Legally sketchy too. Not fun at all!

Something which seems like a more fun path to take appears when realizing there is a derivative of bhyve called xhyve. What if one could mimic the environment I ran for a year, but replacing FreeBSD with a Darwin. Wouldn't that be fun? Resurrecting Open/Pure-Darwin into its third incarnation seems like a suggestion to bring forward. Timely now with it being easter and all. Unfortunately that idea quickly falls flat due to:

xhyve is equivalent to the bhyve process but gains a subset of a userspace port of the vmm kernel module. SVM, PCI passthrough and the VMX host and EPT aspects are/[is] dropped.

Having PCI passthrough is of course absolutely essential. The requirement to implement that would be a bridge too far, to put it mildly. Especially considering how bringing back Darwin would need a huge amount of work, and that running xhyve on that rather than macOS probably already would be quite a project in itself.

macOS

While actually running macOS as it is intended is out of the question, one idea would be to boot it with a heavily modified configuration. With so intrusive changes that it would be unrecognizable as macOS, even if it would technically still be it. I'm imagining taking it to a state where it essentially only hosts a hypervisor running something more sensible operating system. It is a mad idea, which I will not pursuit. A quick search turned up these links on how to run macOS without a gui or reenable >console login, which seem to say that one actually could be able to disable everything unwanted on macOS and use it like a real unix system. Apple doesn't make it easy though. As is apparent from the content reachable by following those links, one might say Apple are even actively making it increasingly harder to turn their consumer devices into actual computers.

alpine linux

In the end I went with installing alpine linux, for at least two reasons. It is a nice distribution, and it is what I have experienced already working for this wifi hardware inside of bhyve. Getting working wifi turned out to still be a bit of a journey, which will likely be part of an upcoming text soon. Suspend and resume worked pretty much out of the box though!

Decades ago I found myself running Debian on most of my systems, and I was happy doing that. While I never did become a debian developer, some might claim I was still fairly deeply invested. I did package software, both my own and other's, and distributed some of it through my personal apt repositories. Had I blogged about it back when it happened, it would probably have been interesting to tell what once drew me to Debian. But that ship has sailed, and this post will instead cover what made me aband ship.

You know how sometimes people attempt to solve problems you're not even having?

Back in my youth we had something called OSS. I can't remember all the details, but I did actually pay money for a license once. It still sucked. Only one process at the time could open the sound device. Thus there was an ongoing struggle to hunt and kill that process in order to instead allow the desired one to play sounds. Then came ALSA and all Linux related sound problems were gone. At least for a while, until suddenly someone did that thing of attempting to solve some fully unexperienced problem, and brought us back to a world resembling the one of OSS. However with the difference that the audio was always stolen by the same culprit. The hunt could be eliminated. We learnt that if we ran sudo killall -9 pulseaudio whenever the computer had gone silent, we got audio working again. Annoying, but only mildly so. It eventually got better. I guess some heroes fixed something.

A few years later history repeated itself. I'm not naming names, and try to not place blame on the doers. One can however not avoid noticing that quality of Debian has seriously suffered since the project decided to fix a problem many people were not at all having. Don't get me wrong. I do understand the challenges of sysvinit, and even was the supervisor for a couple of master thesis students looking at bringing in upstart into the products of my employer back in those days. Still, I wish Debian could have had chosen a path with less random breakage. Too much has already been written about how the pid 1 replacement could had been done better. I have nothing construtive to add, and no illusions that I'll ever feel at home again. I have attempted to run Devuan here and there, but understand it to be an underresourced project with a close to impossible mission.

To be clear, I don't envision a future without ever touching a Debian, or even an Ubuntu, system. However the time when those would had been among my first choice are likely gone forever.

These ramblings might not have added much value, but I still felt it appropriate to post. Apologies to any readers feeling their time being wasted.

Lets start with some background. A few years back I found myself to be stuck in a monoculture. Monocultures as such are typically always a bad thing. Still this was one which I had actively chosen, and once upon a time decided to go all in on. Yet the world tends to change around you, and suddenly you might find what was previously your favorite spot to later be an undesired place. The monoculture in question was Debian Linux. An operating system I then ran on all my computers. Servers, laptops, embedded stuff, everything. For a couple of decades I practically used nothing else. At least not where I could make that choice. It's ironic how I could end up with essentially all eggs in one operating system basket, given my previous experience with and love for more diverse environments.

Now what's written in the previous paragraph is not 100% factual, but it feels true. During the period described I have e.g. been doing software development on both OpenWRT and illumos based systems for customers, and I installed and ran bitrig on a personal laptop for quite a while when that was a thing. I have transitioned into using FreeBSD on both my primary laptop and on servers during the last couple of years. That feels a lot better than Debian. Still, am I perhaps just replacing one monoculture with another? Realizing that I have, not all with working batteries but in total, about seven laptops of varying age I am now trying an insane experiment. Once a day I am switching which operating system to use.

Unless I have tasks that require to be done one a certain system, I attempt to every morning pick the laptop installed with that weekday's operating system. Thus my goal is to run FreeBSD on Mondays, Alpine Linux on Tuesdays, OpenIndiana on Wednesdays, OpenBSD on Thursdays, Darwin on Fridays and Haiku on Sundays. Saturdays are left open for playing around with toy operating systems, or more mature ones, in virtual machines. My aim is to do this for something three to six months or so. Maybe slightly shorter, maybe longer, but definitely not perpetually. I'm not sure exactly what happens after that. I am hoping to learn how to use computers in a more abstract manner, reducing my tendency to unnecessarily make use of too implementation specific details. My expection is to land in perhaps becoming better in selecting platforms suitable for their task. Though any kind of valuable insights are welcome.

Some people who know me might have been shocked to read about my choice for Fridays. Darwin practically means macOS, and that will without doubt be the most challenging part of this experiment. Apple are quite keen on taking away control from users. I am annoyed with that experience already, but hope I will learn something and come out stronger.

Not too long ago I encountered the need for an account again, tried to sign-up and was then given twenty top-view pictures of furnished rooms. I was also asked to select which one would match, from a list of similar looking pictures. I failed.

Could you, dear readers, please help me spot the correct ones?

Find the room that matches the middle image (16 of 20)

Find the room that matches the middle image (19 of 20)

Obviously those two captchas are unsolvable, as both room images match the aerial view. Others have suggested that this might be intentional behaviour, in order to filter out unwanted users. I hold it as more probable that it is simply just a bug. Regardless of which, it makes any attempt to sign-up very time consuming at best and definitely not worth it unless you're desperate to be on a team which does not want you.

Some people might ask: Why would you go through the trouble of closing and opening new accounts rather than keeping a life-long one? A question to which my first reaction would be amazement over the trust people have in that evil entities will never become their enemies.

Rather than leaving the illusion that one would be able to perpetually reach me within a walled garden, I prefer doing the responsible thing and remain only reachable through my communicated and preferred contact channels. Personally, I have always managed to close my accounts before being booted out. Yet you know, either you close your GitHub account yourself, or it is done for you. This platform is all about algorithm driven moderation, with no due process nor ways to appeal. Trust me, in truly technical circles you won't need to ask long before encountering someone who had their account taken away from them for no reason other than a detection of "suspicious activity". Not to say that I actually belong to any truly technical circles myself.

In addition to what I have written above, I'm not exactly a fan of how MSGH actually functions. Compared to other Git workflows, the platform is horrible to use. It hides easy operations behind an extremely unfriendly web user interface. One might argue that it is also possible to navigate using their custom API, and that might be true. Still, even if one were to setup an ergonomic workflow through scripting and custom tooling, there would still be issues. Most annoyingly the fact that, unless you publish a spam-trap email or are lucky enough to have the repository owner adding custom configuration, MSGH forcefully rewrites author headers to junk. Above that, it's beyond me how anyone can be happy with a Git change integration system where it is practically impossible to stack branches in a merge queue.

Dear software maintainers using MSGH, I urge you to please avoid forcing your choice upon others. Clearly merging from another remote must be easier for everyone involved than to do the dance of pointless pull-requests when no discussion is required. In case there are workflows guarding code quality, please make it easy to run those test-suites locally, prior to pushing. Everyone benefits from less administration and more value addition.

An annoyance when editing these files in vim, my editor of choice, has been the lack of syntax highlighting. During the last few days, I read up on the topic, wrote the plugin vim-preseed and published it to vim.org for anyone to download and use. With that plugin installed, anyone can enjoy editing their preseed files with some assistance to conveniently get visual feedback on errors such as missing a backslash at the end of a line or accidentally using a string instead of a select.

Unfortunately the preseed code-blocks in posts on this blog still lack syntax highlighting, but I guess the natural workaround now is to copy and paste them into vim and view them there!

Those slides differ slightly from the version actually shown during the event. Some slides have had aesthetic changes, but the slides are also updated after correcting a major bug. As it turns out, one of the best ways of getting a proper code review is to stand in front of a somewhat large group of people, inviting them to spot your mistakes.

In case blogging also invites similar sharp eyes, it might be appropriate to point out that I do realize the libsyslog-sys crate could probably be considered redundant with the libc crate already exposing the same API. An upcoming release is highly likely to retire it.

With many people using other networks and platforms, it is desirable to in one way or another make those technologies accessible from an irc client. For years I've been having setups enabling sms text messaging with an irc like interface, and there are some vague memories of me being an early enough adoptor of bitlbee to have provided hosting for its web pages in the early days.

A couple of months ago I moved to using my regular irc client for Slack and Matrix, which made for a great increase in usability. However it also resulted in there being too many channels and too little segmentation. Weechat has a feature request in issue #471 with title Support multiple hotlists which could address this problem, but zero progress has been made since the ticket was filed six years ago. Properly designing and implementing that change is a too large project for me to be bothered with. Instead I hacked up micmot, an ugly workaround which kind of accomplishes the same thing.

Multiple Irc Clients Multiplexed Over Tmux (micmot) is a couple scripts for irssi, weechat and the shell to abuse tmux to give an overview over chat activity in multiple irc clients.

                                 _                      __
                      ____ ___  (_)________ ___  ____  / /_
                     / __ `__ \/ / ___/ __ `__ \/ __ \/ __/
                    / / / / / / / /__/ / / / / / /_/ / /_
                   /_/ /_/ /_/_/\___/_/ /_/ /_/\____/\__/

  d Launch weechat for slack as user slack
  i Launch irssi as current user
  w Launch weechat as current user

  q Quit micmot. (Will not kill other panes)

>

[chat] 0:micmot* 1:weechat- 2:[#channel,someone]- 3:slack >"micmot" 23:54 02-Oct-22

As can be seen above, the name for pane number 2 in the status line has been changed from irssi to [#channel,someone], indicating that there are unread messages on the channel #channel and from the person someone in the irssi client. Had there been new messages in the weechat client on pane 1, or the weechat instance named slack on pane 3, those panes would had been renamed too. Visiting a pane resets the name back to the default.

Anyone actually interested in using this is encouraged to clone the repository, read the source code and configure irssi/weechat to load the script(s). Please let me know if finding it useful.

Searching for how others was solving this I found this reddit thread which essentially gave nothing. I also found the tools cash, ccov, mmc, rates, sesters and a bunch of others all claiming to be intended for currency conversion, but with the common limitation that they all only handle exchange rates for the point in time at which they are run. While a pragmatic soul might claim fluctuations even out over time, that's never the perspective held by accountants or tax clerks. Insignificant details such as getting every transaction locked to the exact right day is what they love to enforce, and I do actually understand why they do cause all the annoyance. With it typically being a couple of days between me having an expense and spending the happy fun time to file an expense report or add it to my accounting, the tools above do not meet my need.

For a while I feared I would have to hack up my own little tool. I found this introductionary text on How to handle money and currency conversions by Chris Wenham, and then I realized that rusty-money seemed to be written in accordancy to that text. In essence; use quantified decimal representation rather than fractional floats and always defer conversions as long as possible. That's possibly also true for python-money (pypi) which hasn't been updated for over a decade.

I learned that there are a close to infinite amount of entities providing API:s for currency conversion, but they all require registering for an API key and forming a relationship. Which is way too high maintenance for what I was looking for. The European Central Bank publishes a dataset with daily exchange rates, and that tends to be what sane people actually use. It appears the Swedish Central Bank (SOAP API) provides data too, but short of actually investigating it, I suspect it might just be the ECB's data repackaged.

While looking at possibly implementing the tool in python rather than Rust, I realized that this currencyconverter (pypi) library actually contains a command line utility meeting all my needs. As this does not seem to be packaged by Debian, one must do something like pip3 install --user currencyconverter to install it. Once that is done a call like the following reveals the cost a train ride I had to do for work a couple of days ago:

% currency_converter --to SEK --date 2022-09-16 210 DKK
210.000 DKK = 303.682 SEK on 2022-09-16

Beware that (in version 0.17.1) there is no error detected when converting for a missing date, so make sure to keep the conversion database updated. A convenient way to accomplish that without having to think about it is to add this function to .zshrc:

currency_converter() {
  local python_version="$( python3 --version )"
  python_version="${python_version#* }"
  local max_age=1 # Days of age before refreshing the file.
  local eurofxref_url _eurofxref_file state
  eurofxref_url='https://www.ecb.europa.eu/stats/eurofxref/eurofxref-hist.zip'
  eurofxref_file="$( printf "%s/%spython%s%s%s" "${HOME}" ".local/lib/" \
      "${python_version%.*}" "/site-packages/currency_converter/" \
      "eurofxref-hist.zip" )"

  state="$( find "${eurofxref_file}" -mtime "${max_age}" -printf 'OK' || :)"
  if [ "${state}" != 'OK' ]; then
    wget --output-document "${eurofxref_file}" "${eurofxref_url}"
  fi

  command currency_converter "$@"
}

That wraps all calls to currency_converter, performing an up-to-date check and automatic database download prior to calling the actual command.

While git is great at making interactive rebases of single branches, it quickly gets out of hand when working with multiple branches stacked or chained together. Say for example that we have a situation like the one in the left image below. With topic/some_branch, topic/other_branch and topic/yet_another_branch being actively worked upon and unfinished, while main has moved since work started on this stack of branches. Our goal is to gain a repository like the one in the image on the right, where all work branches have been rebased upon main.

One would of course wish to merge everything early, never needing to end up with having to rebase entire trains of branches. Yet, reality has a tendency to mess with ideal models. That which can not be avoided, needs to instead be handled. Some searching seemed to suggest that people tend to either roll their own scripts or adapt super-heavy workflows to solve this problem. After having attempted to reuse someone else's unmaintained and broken script, I decided to do like everyone else and reinvent the wheel.

Meet git-rb, a script which aids in rebasing related branches by creatively wrapping the editor, by setting the GIT_SEQUENCE_EDITOR environment variable to pre-populate the sequence with labels affected by the rebase:

#!/bin/sh -eu

# Version 2.18 (commit 9055e4) of git added the required 'label' functionality.
_min_major_version=2
_min_minor_version=18

_git_version="$( git version )"
_git_major_version="${_git_version##* }"
_git_minor_version="${_git_version#*.}"
_git_major_version="${_git_major_version%%.*}"
_git_minor_version="${_git_minor_version%%.*}"

unset _git_version

if [ "${_git_major_version}" -lt "${_min_major_version}" ] ||
    [ "${_git_major_version}" = "${_min_major_version}" ] &&
    [ "${_git_minor_version}" -lt "${_min_minor_version}" ];
then
  echo "Git ${_git_major_version}.${_git_minor_version} detected." \
     "Minimum ${_min_major_version}.${_min_minor_version} required." >&2
  exit 1
fi

unset _git_major_version _git_minor_version \
    _min_major_version _min_minor_version

_script_dir="$( dirname "${0}" )"
GIT_SEQUENCE_EDITOR="${_script_dir}/branch-moving-wrapper" git rebase "${@}"

unset _script_dir

That other script, branch-moving-wrapper, does the heavy lifting. It suggests to move every chained branch together with the rebase, and it looks like:

#!/bin/sh -eu

_head=$( git rev-parse --short HEAD )

if ! grep -q '^exec git branch' "${1}"; then
  for _hash in IFS=" " $( awk < "${1}" '$1=="pick" { print $2 }' ); do
    [ "${_hash}" != "${_head}" ] || continue

    for _branch in $( git branch --points-at "${_hash}" | cut -c3- ); do
      _sequence="$( awk <"${1}" \ '{
          if ($0 ~ /^pick '"${_hash}"'/) {
            print; print "label '"${_branch}"'"
          } else {
            print
          }
        }' | awk '{
          if ($0 ~ /^# Rebase /) {
            print "exec " \
                "git branch --force '"${_branch} refs/rewritten/${_branch}"'";
            print
          } else {
            print
          }
        }'
      )"
      echo "${_sequence}" >"${1}"
    done
  done
fi

unset _branch _hash _head _sequence

${VISUAL:-vi} "${@}"

Given that the scripts gets placed in some directory in PATH, one should be able to use git rb --interactive main to have dependant branches move together with the rebase of the leaf branch. Please see the images below for a rebase resulting in a transition between the example from the images above. The lines starting with label and exec are the interesting ones added by the script.

Beware, the above relies on replacing the editor with a script injecting commands into the sequence list and wrapping the editor. It lacks error checking for a bunch of possible scenarios. Only use it if you understand how it works.

By placing the following in ~/.zshrc, zsh can be made to inherit tab completion of options and arguments from git-rebase.

_git-rb() {
  _git-rebase "${@}"
}

compdef _git-rb git-rb

First out is zshenv.illumos which gets conditionally included on illumos (solaris) hosts. It does nothing more than adding a few directories to the start of the list of directories searched for executables, given that those paths exist.

# vim: filetype=zsh sw=2 et

# /opt/onbld/bin/i386 /opt/ooce/docbook-xsl/tools /usr/xpg4/bin /usr/share/lib

for _path in \
    '/usr/gnu/bin' \
    '/usr/ccs/bin' \
    '/opt/ooce/bin'
do
  if [ "${PATH//${_path}/}" = "${PATH}" ] && [ -e "${_path}" ]; then
    PATH="${_path}:${PATH}"
  fi
done

unset _path
export PATH

The second file here zshenv.cloud creates a few convenience functions for easily finding cloud computing instances. The stack exchange links in the comments are pretty much where I have copy'n'pasted the oneliners from, and they are mostly used by my secure shell configuration.

# vim: filetype=zsh sw=2 et

# https://stackoverflow.com/q/25922609/#50535409
#   does-google-publish-a-dns-record-for-google-compute-engine-instances
get_gce_ip() {
  local instance="${1%%.*}"

  gcloud compute instances list --filter="$instance" \
      --format='value(networkInterfaces[0].accessConfigs[0].natIP)'
}

# https://serverfault.com/q/734237/
#   is-there-a-command-to-list-aws-instances-that-results-in-short-output
get_aws_fqdn() {
  local instance="${1%%.*}"

  aws ec2 describe-instances --filters "Name=tag:Name,Values=${instance}" \
      --output text --query 'Reservations[*].Instances[*].[PublicDnsName]'
}

get_linode_ip() {
  local instance="${1%%.*}"

  linode-cli --json linodes list --label "${instance}" |
      jq --raw-output '.[0].ipv4[0]'
}

In order to make your linodes, ec2:s and gce:s conveniently available under some fake top level domains, just add the corresponding cloud.conf somewhere and include it from .ssh/config:

# vim: ft=sshconfig sw=4

Host *.aws
    ProxyCommand nc $( get_aws_fqdn "%h" ) %p

# https://stackoverflow.com/q/25922609/#50535409-dns-record-for-gce-instance
Host *.googl
    ProxyCommand nc $( get_gce_ip "%h" ) %p

Host *.linode
    ProxyCommand nc $( get_linode_ip "%h" ) %p

The third and last zsh config file in this post is zshrc.prompt which is only used for interactive shells. The manual does a better job than I could do at describing how the percent preceeded characters are expanded. One might maybe start out reading it with the understanding that a ternary operator style expression is used to make the prompt red when the previous command failed.

# vim: filetype=zsh sw=2 et

PROMPT="%(?..%S%F{red})%D{%Y%m%d}|%T|%!|%m%#"
RPROMPT="%(?..%S%F{red})"

PROMPT+="%f%s "
export PROMPT RPROMPT

Clearly these are not my full set of zsh configuration files, but a bite sized chunk. Maybe there will be more in the future, maybe not. To some degree that depends on whether these first two zsh posts are well recieved by those who initially requested the topic.