Status update July 2026

hare-lex now handles streams

hare-lex is a general purpose lexing machinery for Hare, and has been developed firmly for hare-template. It works great, but had this design issue: It was requiring for the input bytes to be presented as strings. It was not possible to use it with streams.

This library works by computing a state machine based on the provided regular expressions. Then it crawls this graph to find the longest matching expression. Doing so it has to read the same bytes again and again, to crawl every branch of the machinery. It is impossible by design to support adequately streams, because this would require buffering a possibly infinite flow of data. You can’t predict how long a regular expression match can be. But at least I could have designed it so that the user could work around this limitation.

To do so, I’ve designed a dedicated lexical::buffer stream that the whole library could use as input data. It is similar to the encoding::utf8::decoder, but optimized for hare-lex. The user initialize this stream with an adequately dimensioned buffer, and their source data stream. The stream buffer the currently checked bytes, and is flushed on match.

xdg-dgx (same letters, correct order)

xdg-utils is a commonly installed package that contains XDG related tools. xdg-open by example is a well-known script that open a file or URL in your preferred way (or available way). But as much as I love Shell scripts, this xdg-open implementation is a very frugal implementation of its own specification. For example, it handles poorly the different %f, %F, %u, and %U arguments this the desktop files Exec. Years ago I implemented my own version of this script to handle them better.

xdg-dgx is a new project that implements some XDG related tools, as xdg-open, and provides some Hare libraries.

The dgx-open implementation stick to the specification, download resources for programs that only supports local file paths, and runs multiple instances when they can only handle one argument at a time.

The dgx-terminal-exec implements another xdg-terminal-exec specification so that users can declare their preferred terminals. dgx-open also uses this same behavior when opening a terminal based desktop.

The dgx-desktop-list has been made for Sxmo. It is a simple program that list all available desktop programs, in a script-friendly manner. I have a patch1 in my tree to use it from the Sxmo main menu.

sharetcp E2E

sharetcp is a program I announced in my previous status post. This program is a solution to share a locally available TCP server to someone you trust. This one will be quick, I have implemented end-to-end encryption for sharetcp. The passphrase that both users have to communicate to each-other contains both the salt (and server session identifier), and the password used by the two sides to derive their key.

openrc-user, and sxmo service management overhaul

Since some releases, Openrc announced, then improved its support for user service management. I have been following these topics since them, because I see within openrc-user a better alternative for us. Sxmo currently depends on Superd for that, and it works great, but it would be better to use one service management for both system and user. This drop one dependency yes, but also this improves dependency tracking between user’s and system’s.

Since some months, some improvements have been made to pass environment variables to a service from its own dependencies. An original approach has been made, the services configurations can reexport environment variables for their dependees. The very next release of Openrc could very probably be the one that is mature enough for Sxmo.

I have been talking with navi from sometime (behind every great service manager, there is navi), to help her designing missing features, and even to code directly for Openrc when I can. In the same time, I’m maturing a patch2 for Sxmo to see how it works. I’m sitting on this, and fixing issues as I encounter them. With time, the patch is trimmed more and more, with every openrc-user improvements.

Also, I see in this an opportunity to abstract the user service management on Sxmo. Instead of calling directly superctl, or rc-service -U, we would use a proxy script. This means it could support either Superd, or Openrc-user (and Systemd?).

sxmoconf

This proposal has not been accepted by the rest of the Sxmo community yet. It is an overhaul to improve the way the users configure their Sxmo environment. Sxmo relies presently on file presence (or absence) to toggle features, and on environment variables to configure different behaviors. Those two methods are sometime used in an inconsistent manner, and it is a bit difficult to maintain a convenient documentation for them. Also, it means the user have to restart their Sxmo session to take into account their newly configured environment values.

sxmoconf is a general purpose configuration center. It relies on specification files, formatted as scfg, to structure and document configurable values. Its API has been designed to be comfortable for terminal usage, and convenient to use from scripts.

If this is accepted by the rest of the maintainership, this would still have to wait until Hare programs can be compiled on ARM 32 bits systems. I don’t expect for this to land anytime soon.

hare-getopt-completion

At some point when working on sxmoconf, I thought I should write at least a bash completion scripts. This would make its terminal use-case much more pleasant. I had not written one of them from years, and bash scripts are something really unpleasant to write for me. It would be really great if I could generate this automatically, similarly to what hut completion bash does.

hare-getopt-completion is a library companion module for getopt. It takes the helps, and generate the adequate shell scripts (only Bash for now). Its possibilities are obviously very low, because getopt is really minimalist. Still it autocompletes command arguments, and sub-command arguments in a convenient manner.

It can be used as a getopt subcommand, or if you don’t want to burden the API, as a bootstrap build stage by using the same getopt::help value than your cli. Here a use-case for sxmoconf:

$ sxmoconf<tab><tab>
-h            (Help)
<subcommand>  (Argument)
<args>        (Argument)
list          (Subcommand list)
set           (Subcommand set)
get           (Subcommand get)
del           (Subcommand del)
toggle        (Subcommand toggle)
is            (Subcommand is)
hooks         (Subcommand hooks)
$ sxmoconf list
-h         (Help)
[scope]    (Argument)
[section]  (Argument)