Colas.Nahaboo.net - code

KXF: The Koala XML Form

2026-08-30T00:00:00+00:00

Legacy

A blast from the past... In the last century, when we wrote XML by hand, I designed a format to get rid of one of XML multiple annoyances: as it used ordinary characters as deleimters, such as <, >, &, it means often quoting hell.

The idea: Use non-ascii-7bits characters as markup!

Use «foo» to delimit tags, instead of <foo></foo>
Use these regular elements as escape sequences instead of entities. Escape « by «-». Not really readable — but more than entities — but natural and consistent to parse.

I wrote the KXF <-> XML converter in Klone, my lisp scripting language, that I definitely need to publish here as part of these legacy series.

Here is the doc of the format:

KXF: The Koala XML Form

Purpose

The Koala XML Form XML avatar has been defined with the following design goals:

Ease writing by hand
Ease human readability
Solve only syntaxic problems
- no entities
- no DTD
- no CDATA
- straightforward whitespace handling
- get rid of most quoting hell: use less special chars, and use non ascii ones

Design

Here are some examples:

KXF	XML
«tag»	<tag/>
«tag foo <> bar»	<tag>foo < > bar</tag>
«tag(x=y z="1 2" t='gp') gee»	<tag x='y' y='1 2' t='gp'>gee</tag>
«! comments»	<!-- comments -->
«? PIs»	<?PIs?>

Quoting special chars:

Char	Quoted form	Where
«	«-»	character data contents
»	«+»	character data contents
'	«!»	attribute values
'	«/»	attribute values
"	«#»	attribute values
"	«*»	attribute values

»«/tag» optional ending forms can be used to check nesting as in
«foo a very big contents... »«/foo»
- ending contents is ignored and can be used for comments, as in:
  «foo a very big contents... »«/foo the main loop»
- attributes if present must match the starting tag attributes:
  «foo(x=1) a very big contents... »«/foo(x=1)» matches, but
  «foo a very big contents... »«/foo(x=2)» raises an error
Whitespace around sub-elements are discarded, but not around character data.
You can keep them by postfixing element name with = (it sets the xml:space attribute to "preserve"), such as
«pre=(a=b) «b x» «i y»» or by enclosing them in the pseudo node «= »
«x «= » «y» «z»» keeps space before y, but not between y and z
For comfortable use, it is recommended to assign «» to shift-keypad-minus and shift-keypad-plus respectively
Encodings are raw: either ISO-Latin-1, or UCS2, which can be autodetected as fields must begin with «<letter> (ISO-Latin-1), \0« (UCS2), «\0 (MS UCS2)

Benefits

More readable
Most text editors know how to balance « and » better than <foo> and </foo>
It is self sufficient: whitespace handling is explicit
No need to quote the common chars <, >, &

Drawbacks

You cannot use XML Tools on this format. Not really a problem, as you can convert to and from XML

Tools

For now, there exists only a parser/writer in Klone (xml-ksf.kl, used to implement Klone scripts (xml2kxf, kxf2xml) that converts back and forth to XML.

A java SAX parser is planned

Author

Colas Nahaboo

Back to XML Avatars

My first AI-assisted pull request accepted

2026-08-25T00:00:00+00:00

I just got my first AI-assisted pull request accepted and merged. I must say, I am quite pleased — and a bit humbled: the AI wrote the code, I did the dull part: project manager.

The project is Openfox, a smart local-LLM-first agentic coding assistant. I found a bug: it did not see projects that are symlinks to directories. I keep my git repos in various places, and symlink them into the folder Openfox scans — but Dirent.isDirectory() just tested if a file was a directory, so it failed to detect that a symlink could be a link to an actual directory. Thus symlinked project folders were invisible in the directory browser, the workspace listing, the orphaned-workspace scan, and the plugin listing.

Following my own prompt request idea, I asked Openfox itself — running DeepSeek V4 Flash — to analyze and fix the bug on a local copy. It found the root cause, proposed a shared isDirectoryEntry helper that follows symlinks via stat() (excluding broken and cyclic links), and even produced a careful analysis of Windows junction points. I opened the issue and offered the prompt to the maintainer.

Then I decided on my own to submit a real pull request anyway. My prompt-request post concedes there are cases where a PR is still better — this was one: the fix was small and well-contained, tests existed, and I had a full suite to prove it. Leaving all that on the maintainer would have been rude.

So PR #245 it was: the isDirectoryEntry helper used at all four call sites, with 43 new tests covering symlinked workspaces and the directories API — broken symlinks excluded, and a Windows skip where needed. The full unit suite passed (over 4000 tests), static checks were clean, and I rebased onto develop three times as the upstream moved. Merged as 37e78208, ships in v2.0.125.

Which prompted me to think: the AI used an AI tool - openfox — co-made by AI to generate the code, I did the specs, the validation of the diagnostics, the tests, the rebases, the cross-platform care — and the judgment call to ship a proper PR with full coverage instead of prompt slop. I acted as an auditor, the role that Cringely is saying is our added value for us humans.

walkpadspeed v1: the walkpad app for geeks

2026-08-17T00:00:00+00:00

At last, I decided to declare version 1 of walkpadspeed, my app to drive my Bluetooth walking pad. Two months after the first working version, it is now mature and feature-complete enough to be released as "version one".

The pitch: a single web page that connects to a "smart" walking pad or treadmill over Bluetooth and drives it through a workout you design yourself. No app store, no install, no account, no ads. Open it in Google Chrome on your phone, connect, walk. The walkpad app for geeks!

What?🔗

A walking pad is a bare treadmill: a belt, a motor, and a speed. The "smart" ones (the kind sold with a companion phone app, without a console full of buttons) speak the standard FTMS Bluetooth protocol, which is all you need to control them. So walkpadspeed lives entirely in your browser, uses the Web Bluetooth API, and needs nothing else.

You design your routines as simple text files — each line a step of speed, optional incline, and duration:

HIIT Sprints
3 60 Warmup
6 30 sprint #1
3 30
6 30 sprint #2
3 2m Cooldown

Load the file, pick a routine, start walking. The app handles the timer and the speed changes for you, beeping one second before every change so you are never caught off guard.

Why?🔗

I bought a simple, entry level walking pad (a Fousae ZX-390, many brands sell similar ones: Urevo, Sperax, DeerRun, Costway...), favoring mechanical qualities over sophisticated features. I wanted an app where it was easy to program various routines, as I wanted to experiment a lot.

The existing apps either required expensive subscriptions, or were super complex to program, or had bugs because they tried to cater to very complex treadmills or full health tracking plans. MyHomeFit was the closest to satisfying my needs, but writing programs in their XML format or built-in editor was horrible — you cannot even duplicate a routine or a step — and speeds drifted because it relied on device data and accumulated rounding errors.

So I designed walkpadspeed to "scratch my own itch". And I think all the people like me, wanting freedom to control simply their simple walking pads, will like it too.

What is distinctive🔗

Routines as text files. An open format, terse and editable in any editor — not an XML abomination. Comments, blanks between routines, speeds in km/h or mph, durations in seconds or minutes, optional incline percentages.
Driven by your heart rate. Wear any device using the standard BLE Heart Rate Service (Coros, Coospo, Garmin, Polar, Wahoo...) and the pad speed is auto-adjusted to keep your heart in a chosen zone. There are the usual Z1–Z5 zones, plus a "digestive" Z0 for the optimal effort to reduce glycemic peaks after meals.
Speed that adapts to the day. Nudge the whole routine faster or slower on the fly (+, -, +++...) without losing your place. Feeling great? Tap up. Tired? Tap down.
Modular routines Each routine is composed of steps (a line in the file), and during your workout you can go back and forth steps, and even start at any step.
Test mode. No walkpad on hand? The whole app runs simulated, so you can design and rehearse routines anywhere.
Logs of your sessions. Kept as simple text files, in the same format as the routines, tracking speed, zone, incline and heart rate step by step.
Routines that are shareable. Store your routine anywhere on the web and import it by URL.

Why a single HTML file?🔗

Because I am a fan of the single self-contained artifact — I ranted about it for Go binaries, and this is the same idea for the web. The whole app is one walkpadspeed.html file embedding modern vanilla JavaScript: no build step, no dependencies, no server. Host it anywhere, open it in a browser on a Bluetooth-enabled device, done. I even host a copy at walkpad.fr so you do not have to type a long URL on your phone.

Everything happens inside your browser. Your routines, your Bluetooth connection, your history never leave your device — no server, no account, no tracking.

Installation, Usage, and more info🔗

github.com/ColasNahaboo/walkpadspeed

AI co-written: don't like, don't use.

Bug reports: Favoring Prompt Requests over Pull Requests

2026-08-15T00:00:00+00:00

More and more often, I find a bug in some code that is not mine — often in a language or codebase I barely master. My reflex used to be to hack a fix anyway and send a pull request. But recently I spontaneously began to do the opposite: I let an AI agent fix the bug on a local copy, and instead of a pull request, I submitted the prompt I used — the one that seemed to fix the issue for me, passing the tests. An evolution of my AI without AI?

I did this twice, recently: for the Apollo Zola theme and the Openfox AI harness.

Which prompted me to wonder whether this practice already had a name. I found the CodeRabbit post on prompt requests, which was right on the spot, but nothing else. Hence this post, to draw attention to the matter.

What?🔗

The idea, in short: when you find a bug in a project, and you use an AI coding agent to fix it, do not submit the AI-generated pull request. Submit the prompt you used to fix the bug, with a comment that it seems to fix the bug on your setup, and passes the tests. Plus an overview of the useful info your AI investigation produced: the root cause analysis, the edge cases, the alternative paths tried.

The maintainers can then run the prompt themselves, in the harness and the LLM they are comfortable with — not the one you happened to have at hand — refine it, grill the AI with a grill-me style interrogation, and adjust it to their codebase. Instead of having the pain to review an unfamiliar PR.

This is not my invention, the name already exists: prompt requests. The CodeRabbit article traces the idea to a debate between Peter Steinberger, creator of the self-hosted AI agent Clawdbot, and Gergely Orosz of Pragmatic Engineer. At first I was going to call it "PS" for Prompt Suggest, but let's not reinvent the wheel.

Why?🔗

Maintainers are drowning in PR slop: AI-generated code that compiles, passes CI, and is utterly wrong for the codebase — style drift, redundant helpers, subtle architectural shortcuts. The asymmetric velocity problem: an agent generates code in seconds that takes a human hours to review.

The numbers are staggering: GitHub merged pull requests went from 25 million a month in January 2023 to 90 million a month in March 2026. A 3.6x increase, in an era where the number of human developers did not triple.

The most spectacular example was the 13,000-line AI-generated pull request on the OCaml compiler, rejected by the maintainers, who cited the lack of review resources. The author, Joel Reymont, had "carefully shepherded AI over the course of several days", and, asked why some files credited a maintainer as author, answered "Beats me. AI decided to do so and I didn't question it."

This is so bad that GitHub now lets maintainers disable pull requests entirely, or restrict them to collaborators. Open source projects are starting to close their front door rather than drown.

The root problem: code is now cheap. As Jeremiah Lowin writes in An Open-Source Maintainer's Guide to Saying No: "Historically, we could assume that since writing code is an expensive, high-effort activity, contributors would engage in discussion before doing the work. Today, LLMs have inverted this. Code is now cheap, and we see it offered in lieu of discourse."

Which prompted me to think: if the code is the cheap part, then the value of my contribution is not the diff — it is the investigation. The bug I found, the root cause my AI uncovered, the proof that a fix exists and passes the tests. And the prompt, which is the recipe to reproduce the investigation.

How?🔗

So here is what I think I will put from now on in a bug report instead of a pull request:

**Bug**: [short description, with a reproduction]
**Prompt** (tested, fixes the bug on my setup, tests pass):
  > [the exact prompt(s) I gave to the agent]
**Harness / model**: opencode / DeepSeek v4 flash (or Claude Code / ...)
**Root cause**: [what the AI found]
**Edge cases**: [what the AI's analysis surfaced]

The exact prompt is the key: like a minimal reproduction, it lets the maintainer run the fix in his environment — the harness and model he trusts, in the context of his codebase. He can refine it, ask the AI questions, interrogate it about edge cases. I have a grill-me skill in my own setup, I know it works :-)

Why do maintainers should like it?🔗

No trust question: the code is generated in the maintainer's own sandbox, by his own model, with his own system prompts. The question is no longer "do I trust this stranger's code?" but "does my setup produce a good fix for this prompt?"
Architecture control: the generated code follows the codebase conventions, because it is generated in the codebase.
The maintainer stays the author: he is not inheriting 800 lines of alien code, he is applying an insight to his own project.

And the contributor still gets the satisfaction of having found and fixed the bug — which is the valuable part anyway.

Am I reinventing the wheel?🔗

Partly. The CodeRabbit article is more cautious than me: it argues prompt requests and pull requests are not in conflict, and prompt requests work best before pull requests — review the intent before generating, then still review the code that ships. That makes sense within a team, where you will have to maintain the result, and where determinism, git blame and accountability matter.

My point is narrower, and for a different case: the drive-by contribution. When you fix a bug in a project that is not yours, and you have no intention to maintain the result — which is most bug reports — the prompt is a better unit of exchange than the diff. It is the AI without AI of bug fixing: I provide the prompt, you run it in your own wetware (or your own GPU).

There are cases where a PR is still better: the trivial one-line fix, the case where you will maintain the fix, or the project that explicitly asks for PRs. Use your judgment.

So, next time your AI agent fixes a bug in somebody else's project: resist the urge to git push. Open an issue, and give the maintainers the prompt. They will be grateful, and the code will be better for it.

Maybe a modern twist on the old saying "dont give fishes, show how to fish".

gr: emacs-friendly grep of whole projects from anywhere

2026-08-13T00:00:00+00:00

I just added gr to my colas-bash-lib collection. It is one of the essential tools I use under emacs.

The problem🔗

I am always somewhere deep in a project, and I want to search the whole project, not just the current directory, and quickly go to found hits inside emacs, ignoring ancillary data inside .git dirs and similar.

The solution🔗

gr walks up from the current directory until it finds a mark — a file or directory named .git, .hg, .jj, .ugrep or .gr, indicating the root of the current project — and runs ug (ugrep, a better grep) recursively from there. So from anywhere in the tree:

~/src/foo/sub/sub$ gr max_connections
config/app.conf:12:4:MaxConnections = 100
src/server.go:45:1:maxConnections := ...

The output is the classic file:line:column:line format of compiler errors understood by emacs, with -I skipping binaries and --color=never keeping it clean for piping.

Emacs🔗

The whole thing is designed to play with emacs compile mode. gr prints the header gr: Entering directory \...'— in the exact format emacs expects, and only when it actually changes directory — so the relative paths in the output resolve correctly. Then it is justM-x compilefollowed bynext-error(Ctrl-x) to jump from match to match through the whole project. The precise header matters: emacs is confused by anything that does not follow its convention.

A tip: I mapped F1/F2/F3 for easy use of emacs compile mode:

;; compile: f1 search / f2 next hit / Shift-f2 previous hit
(global-set-key [f1] 'compile)
(global-set-key [f2] 'next-error)
(global-set-key (kbd "<S-f2>") 'previous-error)

Custom marks🔗

For a non-git project — or to define a sub-project root inside a monorepo — just place a .gr (or .ugrep) marker there and gr stops at it. Extra mark names are added with GR_MARKS:

export GR_MARKS='svn cvs bzr fossil vscode env'

Why I like it🔗

One command, from anywhere: no need to know where the repo root is.
Searches everything, tracked or not — which git grep can't do.
Emacs-ready output: browse and jump to the matches instead of eyeballing.
Fast: it is ug under the hood, so no grep -r slowness.

Installation, Usage, and more info🔗

github.com/ColasNahaboo/colas-bash-lib

AI co-written: don't like, don't use.

ups-monitor.sh: staged shutdowns when the power goes out

2026-08-12T00:00:00+00:00

I released ups-monitor.sh, a bash script that decides what happens when the power goes out.

My UPS powers my servers, NAS, main switch and wifi access point. I want to cut off first my workstations in a clean way, to keep as much battery power to provide my main file server access via wifi for my phones and tablets.

Configuring NUT scripts for this seemed verbose and complex for my small setup, so I basically coded a simple but flexible bash control layer over the NUT infrastructure

The staged shutdown🔗

So the script shuts things down in stages, as the battery drains:

90% battery: shut down the non-essential "first" servers — storage, backups, the toy boxes.
80% battery: shut down the "extra" servers.
20% battery: shut down the monitoring host itself, and put the UPS in standby.

The UPS on the final step powers everything off and goes to sleep; when the mains come back, it wakes up, powers the equipment, and the machines can boot again. Recovery is automatic.

The staging is fully configurable: the thresholds and the server lists live in /etc/ups-monitor.conf, and servers can be prefixed h: to hibernate instead of shutdown, or wh:/ws: for Windows hosts.

The config is bash🔗

As I often set up my scripts, the config file is sourced by the script, so it is not a list of options in some syntax, it is pure bash. You can override any variable — and any function. Redefine info to text you instead of mailing you. Redefine remoteshut to do whatever exotic thing your network needs. You can even write "pseudo servers" as funcname:params in the server lists, and the script will run that function before shutting down — say, dump the databases before the machine dies. The anti-framework approach, same as my colas-bash-lib collection.

It just polls the UPS every five seconds, so bash provides simplicity, stability and flexibility with a negligible overhead.

Goodies🔗

A dry-run mode toggled by touch /tmp/NOUPSMON — no restart needed — so you can unplug the UPS and watch the logs before trusting it for real.
Email alerts for power lost and restored, overload, and battery-to-replace. AVR events (TRIM/BOOST) logged with the exact input voltage, for info. Logs rotated monthly, and a clean command for the cron.

Compatible UPS🔗

One advice: choose a pure sine wave UPS, otherwise some active-PFC power supplies may panic and shut down abruptly when the UPS switches to batteries. Save yourself the uncertainty.

Installation, Usage, and more info🔗

github.com/ColasNahaboo/ups-monitor.sh

Note: This is AI-co-advised: chatting with Gemini helped me as a UPS novice, but it did not write the code or the docs.

follow-symlinks: tracing the whole link chain

2026-08-10T00:00:00+00:00

I just added follow-symlinks to my colas-bash-lib collection. It is a small bash script that traces and expands all the symlinks of a file, recursively, and shows you the mount points and the dangling links found along the way.

I made it because there are no existing linux utilities that show both the mount points and the symbolic link traversed to get to the file.

What it shows🔗

Give it the path of a file or directory and it walks the chain, printing each hop:

## /tmp/symtest/chain
  Mount: /tmp
  '/tmp/symtest/chain' -> 'link-to-real'
  => /tmp/symtest/link-to-real

The output is made for human consumption:

-> the file is a symbolic link to
=> the final target
= the path after normalization (resolving /.., /./, //)
Mount: a filesystem boundary — printed when the mount point changes
*** File not found: a dangling link

It also resolves the relative links and the .. segments for you, so what you read is what the kernel will actually open, not the spelling on disk.

The dangling links🔗

Dangling (or broken) links get a useful diagnostic to know the missing link.

## /tmp/symtest/dangling
  Mount: /tmp
  '/tmp/symtest/dangling' -> 'missing-file'
  *** File not found: /tmp/symtest/missing-file
      Because in missing directory: /tmp/symtest/missing-file

The mount points🔗

Links that cross a mount point are easy to miss — the file is the same name, but it lives on another filesystem, with its own space and speed characteristics:

## /tmp/symtest/link-to-etc
  Mount: /tmp
  '/tmp/symtest/link-to-etc' -> '/etc'
  Mount: /
  => /etc

Why I like it🔗

One shot, whole chain: it prints everything in one pass instead of me chaining ls -l and readlink by hand.
A reason, not a symptom: for broken links it tells me the missing directory, not just "file not found".
Pure bash, no dependencies — it only uses readlink, stat and realpath, all of which are everywhere.

See it and the rest of my bash scripts at colas-bash-lib.

browser-freezer: freeze the browser when the screen blanks

2026-08-09T00:00:00+00:00

I have a small NUC-style mini PC that runs linux with X11, and I cannot suspend it — probably some hardware incompatibility or BIOS bug, as is often the case on these mini-PCs. So, to minimize power consumption and heat generation, I made browser-freezer: a small and light utility to freeze the browsers when the screen blanks, and un-freeze them on wakeup. On such a machine, the browser is the only thing consuming power when not being used.

Why two parts? C + bash🔗

It is composed of two parts:

a tiny C daemon browser-freezer that polls the state of the monitor (On / Off) with as less CPU usage as possible (no forks under X11)
on monitor status change detection, it runs the bash script browser-freezer-signal that sends the SIGSTOP or SIGCONT signal to all browser processes (firefox by default). It uses a bash script for the most possible flexibility and customization, as performance is not an issue there.

Wayland🔗

The initial release was X11 only, but two weeks later I added a Wayland variant: a second binary browser-freezer-wayland and a wrapper that picks the right one at login depending on $WAYLAND_DISPLAY. As always with Wayland, it is a second incompatible API to implement, but it works.

My browsers are the only things consuming power on that machine when idle, so freezing them is the next best thing to suspending the whole PC. Indeed :-)

Installation, Usage, and more info🔗

See the browser-freezer repository.

Some code and images generated by AI (Gemini), as my C was a bit rusty.

passgen: a password generator with a memory

2026-08-05T00:00:00+00:00

I just added passgen, a password generator, to my colas-bash-lib collection. It is a tool that lives in your terminal, generates a password, copies it to your clipboard, and keeps a private log of what it generated and for what.

Why a log, you may ask. Because the biggest password problem is not generating strong ones, it is remembering which password goes where. My log solves it in the laziest possible way: I search it when I need to know which password I used for a given site.

What it does🔗

passgen generates a password of length 24 by default, made of lowercase letters, uppercase, digits, and a few special characters. It is careful about the details:

It starts with a lowercase letter, so the password is a valid identifier anywhere.
It deliberately avoids the zero character, to prevent confusion with the letter O.
The special characters are limited to -%=+_^/~?. — the ones that survive a double-click to select the whole password, which is the way I copy things from a terminal.

Then it copies the password to your clipboard, on Wayland or X11 alike. No need to select it yourself.

The log🔗

Every generated password is appended to ~/.local/state/passgen/log, with a date and an optional note. I use it this way:

passgen -l lists the last passwords generated, so I can find the one for a given site.
passgen 32 facebook generates a 32-character password and logs it as the "facebook" one.

The log is chmod'ed to be readable only by me, and I keep it in sync and backed up like the rest of my home directory. It replaced my password manager for everything but shared secrets.

Checking the strength🔗

passgen -s 24 prints the strength of a password of that length in number of combinations, which for 24 characters is about 10^42 — comfortably future-proof even against quantum computers. The default length of 24 is chosen for exactly that reason.

Why I like it🔗

One tool, one habit: no account, no sync, no database, nothing to learn. Generate, paste, done.
The password is in my control, stored in a plain file I can grep, rsync, and back up with the rest of my life.
Useful in a script: pipe it, adapt the length, add a note. It composes like any other command-line tool.

See it and the rest of my bash functions at colas-bash-lib.

x-workspace-switcher: a menu to switch and rename X11 workspaces

2026-08-04T00:00:00+00:00

I switch workspaces dozens of times a day — browser here, terminal there, editor somewhere else — and I could not find a workspace switcher that was convenient. Either they were tiny unreadable icons in a panel, or huge fancy views. I just wanted a readable list of names, plus an easy way to rename the workspace via the programs that run in them.

So I added x-workspace-switcher to my colas-bash-lib, a single bash script in bin/.

Switching🔗

Run it with no argument and a rofi menu pops up, listing each workspace with the classes of the windows currently on it:

1  ws_1 | firefox, discord
2  ws_2 | kitty, vim

So I can see at a glance where everything is, instead of remembering. The current workspace is pre-selected. Move with the arrows or incremental search, hit Enter — or just hit the function key of the workspace you want: F6 goes straight to workspace 6.

Note: I use F6 to go to workspace 6 instead of just 6 to not mess with typing 6 during an incremental search. Also I use Super-F6 as a keyboard shortcut to go to Workspace 6, and using functions keys allow for 12 workspaces (or 14 on my NZXT keyboard :-)

Renaming🔗

x-workspace-switcher new-name renames the current workspace.

That turned out to be the interesting part: there is no standard way to rename a workspace on X11. For instance, I have a script that I run in a git repository that sets up my development environment for it (emacs, kittyies, opencode, ...) and now also name the workspace with the repository name.

Why renaming needs per-WM code🔗

Each window manager does it its own way:

Xfce: xfconf-query on /general/workspace_names
i3: i3-msg "rename workspace to ..."
bspwm: bspc desktop -n
GNOME: gsettings on workspace-names
KDE: kwriteconfig plus a qdbus reconfigure
anything else: a python-xlib fallback that rewrites the _NET_DESKTOP_NAMES property directly

Detection is via wmctrl -m, helped by XDG_CURRENT_DESKTOP when the WM name is ambiguous.

The Wayland question🔗

As always with Wayland: alas, no. The core protocol has no workspace support, and each compositor invents its own incompatible API. My switcher is X11 only — save your sanity, use X11. :-)

Installation, Usage, and more info🔗

See the colas-bash-lib repository, the script is bin/x-workspace-switcher. It needs rofi; renaming on some WMs needs extra packages (i3-wm bspwm plasma-workspace python3-xlib).

Just copy the script in your PATH (/usr/local/bin, ~/.local/bin/, ...), and bind it to a keyboard shortcut for convenience. For instance I bound it to Super-W (aka Windows-W) since I bound all my window and workspace management function to Super shortcuts.

License🔗

gmail-to-fastmail: keep your Gmail labels in sync on Fastmail

2026-08-03T00:00:00+00:00

I moved to Fastmail some time ago, but like many of us I kept one foot in Gmail: Fastmail's "fetch" tool keeps duplicating my incoming Gmail into my Fastmail account — a backup, an escape plan, and a bridge for family members who are not quite ready to leave Gmail yet.

But there was a hole: the labels I add on Gmail after the initial migration (manually, or with my rules) were never reproduced on Fastmail. So I wrote gmail-to-fastmail, a single Go binary that incrementally syncs your Gmail labels to Fastmail.

How it works🔗

It reads your Gmail via IMAP (read-only, X-GM-LABELS), and applies the labels on Fastmail via JMAP (a more efficient variant of IMAP), in batches of 10 000. Progress is kept in a local SQLite database, so each run resumes where the last one stopped — once caught up, a run takes about 15 seconds. Perfect for cron.

What it does🔗

Labels mapped: your Gmail labels become Fastmail labels, created on demand, never deleted.
Categories: Gmail's system categories (Inbox, Updates, Social...) become underscore-prefixed labels _Inbox, _Updates, _Social...
Trash: emails deleted on Gmail are not deleted on Fastmail, just labelled _Trash — a backup of your deleted mail, with an easy way to "empty the bin".
Local cache: unchanged emails are skipped, so Fastmail's API is left in peace.
Mirror mode: -m/-M optionally imports emails missing on Fastmail, not just labels. There are more options, detailed on the GitGub repository.

Installation, Usage, and more info🔗

See the GitHub repository.

Why Go?🔗

Because it is a single self-contained binary with no runtime dependencies — you know my thing about that. No Python env, no node_modules, no nothing. Free (MIT).

Also, AI co-written: don't like, don't use.

mailpixtracker: a lightweight bash CGI to track emails

2026-08-01T00:00:00+00:00

When I send an email, did the recipient read it? So I wrote mailpixtracker, a small self-hosted CGI script that tracks when your emails are opened, via the classic invisible 1x1 pixel trick.

Think of MailTracker or MailTrack, but without all the marketing machinery: no account on a third-party server, no spyware concerns, no "business intelligence" dashboards. Just three bash scripts on your own web server.

How it works🔗

You create a new tracker with an optional name on your mailpixtracker page. It gives you a tiny HTML snippet to paste in your email such as:

<img src='https://my.mailpixtracker.org/_/12-I5rHJCFap' width=1 height=1>

When someone opens your email and their mailer loads images, your server logs the request: date, IP, hostname, user-agent. No data ever leaves your server.

Features🔗

No accounts: The URL is the authentication, via Capability URLs. The admin URL is your unguessable "password" — share it with nobody and you are safe.
Plain files: Logs are tab-separated text, one line per open. No database.
Colored logs: Each distinct IP gets its own perceptually-spaced color, so you can spot repeat readers at a glance. Your own opens (while composing the email) show in dim grey, so they do not pollute the picture.
New entries highlighted: Entries added since your last visit get a yellow marker.
Notes field: Each tracker has an editable name and notes — handy to remember what you sent, to whom, and when.
Guest accounts: Create isolated spaces for different purposes (work, family, surfing...) with admin (you) accounts, or guest accounts that you can just give to others with a link. Non-admin guests only see their own trackers.
Geolocalization (optional): With the MaxMind databases installed, logs show the organization and country of each reader.

Caveats🔗

Email tracking is not foolproof. Most mailers now prompt before loading images, so people can read your email without ever triggering the tracker. Mailpixtracker will not tell you everything — but when it does fire, it is accurate, and the logs are all yours.

Also note that it is a tool for personal curiosity, not for marketing analytics: it has no click tracking, no A/B testing, no "campaigns". If you want that, there are plenty of SaaS products; this one is the lazy, self-hosted, private alternative.

Install🔗

For instructions, see the code is at github.com/ColasNahaboo/mailpixtracker, it is multi-licensed (MIT, Apache 2.0, MPL 2.0, LGPL v3, GPL v3) — pick whichever suits your project.

Fanatic of the single self-contained executable

2026-07-31T00:00:00+00:00

I am becoming more and more a fanatic of the single self-contained executable, with no runtime dependencies, that Go provides: one binary, forever. No npm, virtualenv, docker, flatpak, snap... no version hell.

The qualities I lived with and took for granted during my years of coding in C and shell.

To the point that when I find now a python/node/java/ruby/php piece of software I would like to install, my first reflex is to just recode the darn thing in Go. I know, I know, rewriting a perfectly working piece of software just to avoid a dependency is bordering on insanity, but the result is so satisfying... A single file that will still run in 20 years, with no upgrades, no breakage, no maintenance.

And with AI, now, it is becoming less and less insane!

(Bluepost )

filewebx: a simple, private, web file exchange

2026-07-30T00:00:00+00:00

I often need to send files to people — photos, documents, archives — and I got tired of the usual suspects: WeTransfer limits you, SwissTransfer is great but you depend on a third party, and all of them impose size caps, retention limits, and account management overhead.

So I wrote filewebx. It is a self-hosted CGI Bash system for private file exchange, using Capability URLs: you upload a file, get back a non-guessable link, share it. No logins, no passwords, no accounts.

It is your own private WeTransfer / MASV / Smash / SwissTransfer, on your own server.

What it does🔗

No accounts needed: The URL is the authentication. Your secret admin URL (e.g: https://your.site/yJDdYNEXmB) is your dashboard. Share it with nobody, and it is secure.
Guest accounts: Create isolated spaces for other people by just giving them a link. They can upload and get their own shareable links without seeing yours.
Auto-expiry: Files expire after a configurable delay (100 days by default). A daily cron job cleans them up.
Nice interface with for instance an upload progress bar, easy copying of the url, nice colored logs that work without JavaScript frameworks; Just plain HTML + CSS + JS served by a Bash CGI.
Slug URLs: Download links are readable: https://your.site/_/OLw6bZrh65lj/my-photo.jpg instead of raw url-encoded gibberish.
Geolocalized logs: See where downloads come from, with IP colors assigned via golden-angle hue sampling to spot patterns at a glance.
Quotas: Reserve free disk space. Per-guest quotas available.

How it works🔗

Three bash scripts, one web server, a single directory for data. Uploads go to data/, metadata is stored as bash associative arrays via declare -p (from my colas-bash-lib). The download script (_) logs access and serves the file. The admin script handles the UI, guest management, and cleaning.

The whole thing is plain files — no database, no Docker, no snap, flatpak, no dependencies beyond iconv and a CGI-capable web server (tested with Apache).

Why bash?🔗

Because for a CGI system that runs once per request, startup time does not matter, and bash makes deployment trivial: copy three files, rename one to your admin password, done. No compilation, no npm install, no virtualenv. No dependencies on library that can break at any time in the future. It works now, it will still work in twenty years and more. Also, the bash associative array metadata format (declare -p) is surprisingly practical as simple database — it is both human-readable and machine-parseable without a custom serializer.

Guest accounts🔗

You can create guest accounts from the admin tab. A guest only sees its own files. Mark a guest as "admin" to get a link back to the main admin account — useful for creating separate namespaces for different audiences (work, family, surfing buddies).

Non-admin guests cannot access the main account, see other guests, or create new guests. Perfect for giving to people who just need to send you a file.

Deploy🔗

Create a directory on your server with data/ and cgi/ subdirectories.
Copy filewebx as your admin password name into cgi/.
Copy filewebdl as _ into cgi/.
Copy cgibashopts into cgi/.
Set up a virtual host, add a cron job for daily cleanup.
Done.

See the README for full install instructions and Apache config samples. Configuration is done via a single bash-syntax file: set validity, passlen, freequota, guestquotas, and a few more.

What I like about it🔗

It is the simplest thing that works: data is plain files, so I can ls, grep, rsync everything without special tools.
Capability URLs mean I never have to manage a user database. The random tokens are generated from /dev/urandom — 12 characters give about 10^14 combinations.
The log coloring with perceptually-spaced HSL hues makes browsing download history genuinely pleasant.

The code is at github.com/ColasNahaboo/filewebx, MIT license. Contributions, issues, and ideas welcome.

Save these Firefox tabs for later

2026-04-13T00:00:00+00:00

I often look for some concept out of curiority, and end up with tens of browser tabs opened on the subject, and realize that I have no time now to pursue this rabbit into his hole, end up with tons of Firefox windows with tens of tabs gathering dust (and eating RAM) on my desktop. Up to now I just created Foswiki pages or Trello tasks as reminders to tackle these projects later on, but it required enough manual work to often postpone doing it and either losing the info or be swamped in thousands of tabs. And saving them as Firefox bookmarks was cumbersome and required lots of manual management.

What I decided to do is a simple way to save all these tabs offline, and be able to re-open the window simply. I bundle them into what I call .ffst files (for FireFox Saved Tabs), simple text files of one url per line, into a ~/firefox-savedtabs/ directory.

Saving a set of tabs:
- Select the tabs (click on the first one, shift-click on the last one)
- Open the right-mouse-button menu on a tab, and select Copy URLs
- Create a new file (e.g: some-name.ffst) in the ~/firefox-savedtabs/ directory with your favorite editor,
- Paste the tabs into it,
- Save.
Restoring the tabs into a new window: either by:
- running the script below firefox-savedtabs-restore without arguments, and choosing which file to restore.
- running the script with the ffst file as argument:
  firefox-savedtabs-restore some-name.ffst
- Browsing the directory ~/firefox-savedtabs/ in a file explorer window, and choosing to open the .ffst file with Firefox SavedTabs restore once you have created the ~/.local/share/applications/firefox-savedtabs.desktop file below

I can thus just mention the .ffstr file in my various "todo" places (TODO lists, TODO files, pinboard, wikis, trello, ...)

Note that you can adapt this to any browser, and choose whatever directory name and file extension you want.

Updating the tabs is just re-copying the urls and re-pasting in the file.

The two scripts are:🔗

/usr/local/bin/firefox-savedtabs-restore🔗

Note that you can modify in it the restore function to use with another browser.

#!/bin/bash
# shellcheck disable=SC1090,SC2155,SC2046 # source files, declare&assign

# restore saved tabs bundles (text files of urls, one per line)

dir="$HOME/firefox-savedtabs/"

restore(){
    mapfile -t urls <"$1"
    firefox --new-window "${urls[@]}"
    exit 0
}

if [[ $# == 0 ]]; then
    # Without args, list the saves, most recent first, and prompt to restore
    echo "In ~/.firefox-savedtabs/"
    cd "$dir" || exit 1
    select i in $(find . -type f -name \*.ffst \
                    -printf '%TY-%Tm-%Td.%THh%TM:%TS %h/%f\n' | \
                   sed -e 's| [.]/|_|' | sort -r | \
                   sed -re 's/:[0-9]{2}[.][0-9]*//'); do
        restore "${i#*_}"
    done            
else
    # with a file name or path, restore the window
    file="$1"
    if [[ -e "$file" ]]; then
        restore "$file"
    elif ! [[ -e "$file" ]] && [[ -e "$dir/$file" ]]; then
        file="$dir/$file"
        restore "$file"
    else
        echo "***Error: file not found: \"$file\" in $dir"
        exit 1
    fi
fi

[Desktop Entry]
Name=Firefox SavedTabs restore
# update-desktop-database ~/.local/share/applications/
Exec=/usr/local/bin/firefox-savedtabs-restore %u
Type=Application
Terminal=false
MimeType=x-scheme-handler/x-firefox-savedtabs;

Converting Zola pages from TOML to YAML

2026-04-07T00:00:00+00:00

Since Zola now supports frontmatter in its markdown pages in the YAML format in addition to the original TOML, I decided to migrate all my pages to YAML, as it is both easier to read and write for humans, and natively understood by a majority of tools (Emacs, marktext, obsidian, vs-code, typos, zettlt...)

So I wrote a small bash script for the conversion, site-toml2yaml (all my personal site management tools start with the prefix site- for taking advantage of the tab-completion). It should run on any Linux or Unix system, and it requires dasel and the usual gang: grep, sed, head...

Note that you could also use hugo convert, but I haven't tested it.

You can grab it at my zola-tools repository. This repository is quite empty for now, but I will use it to publish the various small tools I use to maintain this public site.

Usage🔗

site-toml2yaml md-files or directories...

Converts in place the frontmatter of Markdown files from TOML to YAML.
It recurses in directories, but looking only for *.md files and sub-dirs.
Without argument, run on ${ZOLA_ROOT}/content/
Should work on any Markdown files with TOML frontmatter.

You should only run it on your content/ dir normally. For instance running it on your themes/ dir will risk messing your imported themes

WARNING: it modifies the files in place, so MAKE A BACKUP before running it!

Why converting to YAML?🔗

TOML is arguably a better configuration file format than YAML, but only if you want to use it as a simpler JSON, i.e. a well-specified, unambiguous way to represent any data.

However, I feel that for the simple and limited use case of Zola pages frontmatter, it is overkill and thus a real pain to read and edit by hand. Let's take an example:

TOML

[table1]
    foo = "bar"

    [table1.nested_table]
        baz = "bat"

[[comments]]
author = "Nate"
text = "Great Article!"

[[comments]]
author = "Anonymous"
text = "Love it!"

YAML

comments:
  - author: Nate
    text: Great Article!
  - author: Anonymous
    text: Love it!
table1:
  foo: bar
  nested_table:
    baz: bat

See? Especially for people like me with a Unix culture, the YAML format seems both more natural (resembling the format of email or HTTP headers, the use of indentation à la Python), and TOML has a repulsive Windows flavor. Add to this that most of the tools I use understand natively YAML frontmatter but not TOML, and the decision is easy.

Explicit Action Pattern keeps you in the flow

2026-04-05T00:00:00+00:00

When designing interfaces for tools for my personal use, I have been using what I call an Explicit Action Pattern, the opposite of modal design. Due to the general trend towards minimalism of modern UI practice, it is not used a lot, but I think it should, and here is why.

Examples🔗

Explicit Action Pattern	Modal Design
Initial Search	All movie music ebook
Search results...	All movie music ebook

As you can see in the top row, for searching an ebook, I will "flow" through the form from left to right, filling the relevant field and hitting the return key, or pressing the "Search EBook" button. But with the traditional modal design, choosing the radio button "ebook" breaks my flow of entry.

On the second row, you can see how I use this design for providing a "search again" form, where I can choose to enter a new search, or edit the previous one by selecting the relevant search box. It treats the search interface like a REPL (Read-Eval-Print Loop) rather than a static webpage. Whereas in the traditional way, I would have to break my flow to go hit the "Clear" button to empty the field.

Interaction flow🔗

So, rather than breaking the flow of the interactions to set modes, you just flow seamlessly into branches of the decision tree. If we take a car driving analogy, you just choose a direction when encountering a fork in the road, rather than having to get out of the car to move a barrier before resuming your ride.


graph TD;
    User((User Interaction));

    %% LEFT SIDE: Explicit Pattern (Parallel)
    subgraph Explicit ["Explicit Action Pattern (Parallel)"];
        FormB[Dedicated Form: Search Books];
        InputB[/Input Field: Books/];
        FormM[Dedicated Form: Search Movies];
        InputM[/Input Field: Movies/];
    end;

    %% RIGHT SIDE: Modal Pattern (Sequential)
    subgraph Modal ["Modal     Design (Sequential)"];
        FormS[Single Search Form];
        %% The Vertical Spine (invisible link to keep things straight)
        FormS ~~~ InputS[/Generic Input Field/];
        %% The "Hook" - Positioned to the side
        Mode{{Mode Selection: Books vs Movies}};
    end;

    %% Explicit Connections (Direct Flow)
    User --> FormB;
    User --> FormM;
    FormB --> InputB;
    FormM --> InputM;
    InputB --> Submit((Submit));
    InputM --> Submit;

    %% Modal Connections (The Hook Flow)
    User --> FormS;
    FormS --> Mode;
    Mode --> InputS;
    InputS --> Submit;

    %% Styling from original source
    style FormB fill:#f9f,stroke:#333;
    style FormM fill:#f9f,stroke:#333;
    style InputB fill:#ccf,stroke:#333;
    style InputM fill:#ccf,stroke:#333;
    style Modal fill:#f5f5f5,stroke:#999,stroke-dasharray: 5 5;
    style FormS fill:#eee,stroke:#999;
    style Mode fill:#fff,stroke:#333,stroke-width:2px;

Benefits🔗

This Explicit Action Pattern has many benefits for power users:

Distributed Entry: Breaking one complex task into multiple simple, dedicated entry points.
Parallel UI: Presenting all options simultaneously rather than hiding them behind a selection step.
Non-Modal Interaction: Avoiding the "mode" where you have to set a state (e.g., clicking a radio button) before you can perform the actual action.

For the examples above:

Feature	Separate Dedicated Fields	Single Field + mode switches
Cognitive Load	Higher initial load (more to look at), unless you are already used to this UI.	Lower initial load (cleaner look), especially for novices.
Physical Effort	Lower (Click bar → Type → Enter).	Higher (Click radio → Click bar → Type → Enter).
Intent Clarity	Absolute from the moment you click.	Ambiguous until the modifier is set.
Screen Space	"Expensive"; requires more vertical/grid space.	Efficient; fits in a header.

This is essentially applying Functional Programming and CLI philosophy to a GUI.

Immutability: The pre-filled field is the "original state."
Pure Functions: Each input field has a single, predictable output.
No Side Effects: Clearing one field doesn't break your ability to see the other.

In a nutshell, Directness over Modality.

For power users🔗

If you are used to CLI environments, or using mostly keyboards shortcuts in interfaces, or editors like Emacs or vi, your brain likely functions on "Command-Action" pairs. And Explicit Action Patterns offers you:

Muscle Memory: You can bind a specific field to a specific mental "slot." You don't have to check the state of a radio button before hitting enter; you know which field you are in. It transforms a two-click "hunt and peck" task into a single-click muscle memory task. You don't have to wait for an animation or look for a label; you just hit the coordinate on the screen you already know.
No "Context Switch" Tax: Selecting a radio button is a "mode switch." It requires you to stop thinking about your search query for a second to handle the UI mechanics. Separate fields eliminate that tax.
Visual Affordance: The label "Search Movies" is context-free, an immediate call to action. A generic "Search" box is a mystery until you look at the surrounding buttons.

In the real world🔗

While interfaces have moved toward the "Google-style" of Modal Design to flatten the learning curve for the general public, many expert-level interfaces still rely on the Explicit Action Pattern. You can find it in library catalogs, Bloomberg or Reuters terminals, and high-end enterprise software.

You can also see this approach in media editing software. Instead of a single "Save..." dialog that asks for a format later, you often have explicit menu entries: "Save," "Export as PNG," "Export as JPG," or "Export as MP3."

And one can consider that the Unix philosophy of having one tool per function, instead of mega-commands with tons of options is also an embodiment of the Explicit Action Pattern.

Dive deeper🔗

This approach is highly "discoverable." You don't need to learn "how the search bar works"; the interface tells you exactly what it can do by simply existing. This is what ihas been advocated by many Usability experts, that I consider mandatory reads:

The boss: Alan Cooper books, especially About Face: The Essentials of Interaction Design.
The enjoyable Don't make me think by Steve Krug.
Direct Manipulation by Ben Shneiderman
Data Density the examples above being described by him as "Parallel Input".
The human Interface by Jef Raskin, especially his "Monotonicity": the idea that a specific goal should always be achieved by a specific, unchanging set of actions.

Foswiki update script

2026-03-26T00:00:00+00:00

Although I have migrated my public site to zola which was on Foswiki, I have decided for now to keep my private family wiki on Foswiki for now.

So I needed to upgrade it to 2.1.11, it was still in 2.1.6, and since the upgrade is not exactly intuitive, I made a bash script to automatise the upgrade.

You can find it on GitHub.

See also its publication on the Foswiki site, with a reminder of the standard upgrade method.

How the Script Works🔗

This script supposes a modern version of Foswiki (v2+): it blindly overwrites the files that should not have been modified, so when customizing your wiki be sure to never directly modify distributed files.

The script however will not overwrite blindly any topic file that has been edited via Foswiki itself, by checking the author metadata. It will perform a 3-way merge, as automated as possible.

It also works only on a local copy of the site. You will have to download yourself a copy of your site, upgrade, and then re-upload it in place. This keeps the script simpler and safer.

It works on linux, but should work in linux-like layers on top of other OSes, such as cygwin, WSL, Homebrew, ...

Why staying on Foswiki?🔗

My private wiki is used by me, but also my wife, who is not really fluent in wiki or markdown editing, so an excellent WYSIWYG is a must. And personnaly, I hate databases and strive for stability and simple architecture. Foswiki has all these qualities... and I would have a lot of content to convert.

But I will probably switch to an open source markdown-based wiki with a very good WYSIWYG editor and flat file storage, and easy to maintain. For now I see 3 potential candidates:

SilverBullet, still evolving but very promising
OtterWiki, minimal but seems powerful enough
Wiki.js the current leader, but I will wait for the v3 as the v2 to v3 migration do not seem automatic, and the development seems to have slowed greatly

Suntimes, a small shell utility

2022-03-03T00:00:00+00:00

I just made a small command-line utility to display the sunrise and sunset times at a location. It can be quite useful in shell scripts.

It is a minimal Go wrapper around the nathan-osman/go-sunrise library

You can find it at my repository: GitHub - ColasNahaboo/suntimes

One year retired

2022-02-24T00:00:00+00:00

I have been retired for one year now, and what happened? Well...

I basically stopped coding and reading about anything computer-related for eight months. I didn't expect it, I was thinking I would start coding at once, going through my huge todo list of various projects.
I enjoyed being able to go SUP surfing at will, but I ended up actually less on the water than before, simply because i didn't feel pressured into going on the water if the conditions were not enjoyable: I have now all the time in the world, I can wait for better conditions.
I started what I should have done years ago: Stretching at least 30 minutes daily, and warming up a full 10 minutes before going surfing. Work and play for me were mainly sitting in front of a computer, and I had become awfully stiff. I will detail my routine in later posts, it is worth it.
I dived deep in modern physics: astrophysics, cosmology and quantum mechanics. This also will warrant a full separate post.
I started re-coding in the last four months:
- The first month I began working on various bits of code (shell scripts), progressively getting back to speed, and also deciding to learn the language Go. I was looking for a very longtime for an efficient language to replace lisp or C as compliment to scripting (I never liked Java), and was hesitating between Rust and Go. A discussion with Olivier Arsac convinced me to try Go.
- I switched to git (I was using mercurial) for version control, and moved my publicly available source codes from my personal web site to my GitHub. It may sound ridiculous, but at now 61, setting things up so they do not disappear when I do is becoming an important consideration. I will thus progressively stop using self-hosted sites to publish on places that will survive me, as nobody in my family is tech-savvy enough to maintain a web site.
- Then in December I stumbled upon the Advent of Code challenge that I decided to do in bash for the challenge, and it was unexpectedly productive? I learned more in these 25 puzzles than in my last 10 years of professional bash scripting. You can see my solutions in my post Bash lessons learned with AoC 2021.
- Thus, after finishing the Go tutorial, I decided to do the previous AoC years in Go. And I just finished the AoC 2015 in Go. This definitively made me a Go enthusiast, I realized that the designers of Go had exactly the same opinion of what should be a general programming language: They worshiped readability, simplicity, performance and maintainability while hating inheritance and the feature creep of most modern languages.

That was my first year. And now, embarking for the next one!

Completed the 2015 Advent of Code challenge in GO

2022-02-24T00:00:00+00:00

And I completed the 2015 challenge! (see my previous post). You can read my notes on it on my GitHub.

This was quite interesting, and I thing a great way to learn a language just after completing its tutorial, as this challenge as a feel of "real life" situations, and allow for a variety of solutions, so that you can put different approaches to the test.

I forced myself to not look at the solutions available on the net, except for two cases:

Using working code to generate more data to test against (random inputs + expected result number). I just ran the code of other solutions, without reading their source. I often used solutions by devjobe and schwern.
Once I had a working solution, browsing the source code of other solutions to compare with mine and see where I could improve, and discover cool tricks. I mostly used the reddit megathread.

I also tried to use only the standard Go packages, and not the ones available on the web. I am sure I will end up using 3rd party packages to replace the standard ones (the flag package to parse options for instance is really too primitive). And I also didn't create a separate module or package for my library of common useful functions. I will surely do it in the future, but I feel I should have more experience first.

Anyways, it has confirmed that Go was the language I have been waiting for all these years. On the one hand, I have a bit of regret not having jumped on it sooner, but on the other hand it was easier to just wait for my retirement (one year ago) to free myself from any work politics and constraints to be able to fully explore the programming language landscape with no strings attached.

I can see myself using 4 languages in the future:

bash for any "glue" tooling and scripts.
go for my main do-it-all language, and web backend.
javascript (and/or WebAssembly) for my web frontend, with pure modern HTML and CSS, but no framework, à la Vanilla JS.
and maybe a higher performance, specialized language, if I encounter such needs: E.g: zig as a replacement of C for tasks where Go could be unsuited (if I encounter any), or julia for math-specific things, etc...

Edit: I see that Neil Henning also enjoyed discovering a new language via AoC: A Review of the Zig Programming Language (using Advent of Code 2021)

Starting the 2015 Advent of Code challenge in GO

2022-02-09T00:00:00+00:00

I discovered the advent of code in 2021, and did it in bash for the challenge. But since I started learning GO, I decided to code the previous AoC years in GO as a mean to practice it. So, although my bash code can be useful to see some tricks of a seasoned bash programmer, these GO solutions must be considered as "student code".

So I started coding the 2015 year of AoC in GO, available on my GitHub: advent-of-code-my-solutions/go/2015

The code is in GO, with some housekeeping scripts in bash.

My bash library on Github

2022-02-05T00:00:00+00:00

I have started to publish on Github, at colas-bash-lib, my collection of various bash functions I reuse often in my bash scripts.

Fell free to copy and use in any of your projects or compilation of bash tools.

I have tried to make them the fastest possible, by avoiding forking sub-shells or external commands, and benchmarking extensively to compare the possible way of coding them. Of course, I will gladly accept suggestions or code to make them faster. But it means that error checking is often terse and minimal, and readability of the code was not a priority.

I have a kind of «anti-npm» approach, in that I copy these functions into my scripts rather that using hem as a true external library that I would load at runtime. It thus avoid installation issues, and the ependency problems that may arise from automated upgrades.

Bash lessons learned with AoC 2021

2022-01-11T00:00:00+00:00

I completed all the exercises of the Advent of Code 2021 in bash! (see my previous post)

You can find my solutions with comments in my GitHub repository at https://github.com/ColasNahaboo/advent-of-code-my-solutions/tree/main/bash/2021

I must say I "cheated" a bit. My solution for the Day 24 was too slow in bash, and as I was a bit out of steam, I did not try to find a smart algorithm. I just noticed that I solved it by building a bash arithmetic expression (of 1 million characters...) that I then evaluated in bash, and since its syntax was exactly the one for C... I just made the bash script compile the bash expression in C and execute it, using the C compiler as a bash arithmetic just-in-time compiler :-)

I just discovered AoC this year, and I am impressed. Challenging, fun, and a great way to progress. I am going to do the previous years, too, but in "real" languages this time. At least ones with data structures... I will start with Go.

What I learned:🔗

Coding in bash is not so bad, even if it can border on insanity at times :-).
Modern bash features are often overlooked but very useful.
Passing shellcheck should be a mandatory goal for each bash programmer. I resented it at first since I thought it was adding unecessary syntaxic sugar to my code until I realized that it was a symptom that my coding style was the problem.
Use [[...]] for strings and ((...)) for integers other any of the legacy constructs like [...], test, etc... The code is then much cleaner and safer (and a tad faster), as you do not have to quote as much. E.g: [[ -z foo ]] instead of [ -z "$foo" ], or even ((i=j)) instead of i="$j"
- but, this makes traditional debugging with set -x less useful as the values of variables are not displayed anymore. E.g if j is 2, the tracing of i="$j" shows i=2 whereas the tracing of ((i=j)) only shows ((i=j)). This could be where a bash debugger would be useful, but I know only one, bashdb, and it does not seem updated anymore, and I could not find a version working with bash 5.1. The trap DEBUG trick can be useful, though.
- So, I tend to write now i=$((j+k)) while developing code, and maybe later for production switch to the a bit more efficient ((i = j+k))
I avoided arrays in bash because I found out they were abysmally slow when first introduced, to the point that managing data in files with grep, sed, ... was actually faster than using arrays. But not anymore! Bash arrays should now be used as much as possible.
A lot of bash functions can "map" on arrays. For instance ${tab[@]//x/y} will string-replace x by y in all the elements of the array tab, and is super fast.
Use arrays rather than the classic way to represent lists in bash by space-separated (or tab-separated) substrings in a string.
Bash can have typed variables: integer ones via declare -i or local -i, and using them makes your code safer.
Bash functions can be passed variables by name, useful for efficiency to avoid copying big arrays or strings, and to provide multiple return values by modifying passed variables. But it cannot recurse as it is not a passing by reference, but by name.
Working with arrays makes using $(...) impractical, as commands are executed in a subshell and cannot access arrays anymore to update them in the parent shell. So I tend to pass the return value(s) into global variables of the same name of a function. E.g. instead of x=$(foo), I write foo; x="$foo". Or pass variables by name to set them if I want to return multiple results.
To parse a space-separated string, the fastest is using set to map the elements in the positional parameters $1, $2, ... then the ${string#* } and ${string% *} operators are the fastest, closely followed by a read, the full [[ $string =~ ([-[:digit:]]+)[[:space:]]... ]] being 3 times slower. And if possible, using indexes is even faster: ${string:i:j}.
Use the faster $(< filename) instead of $(cat filename).
To copy an associative array A1 to A2 in bash 4.4+, do: A1_def=$(declare -p A1) && declare -A A2="${A1_def#*=}"
To access more than 9 parameters in a function: use braces: $10 wont work, but ${10} does.

Moving to Github

2021-12-10T00:00:00+00:00

Warning: I will move all the sources I maintained on my own mercurial web instance in hg.colas.nahaboo.net to my GitHub repositories: https://github.com/ColasNahaboo/

I have thus redirected the non-functional hg.colas.nahaboo.net to this page.

The move will be gradual, I started with rsync-incr, and I hope to have finished before the end of 2021. Please ask me is you do not see yet your favorite source there.

The reason is that Debian has phased out most of what the web tools for mercurial rely on (python2, wsgi, ...), and thus my web hg repository was broken. And since I wanted anyways to move it to GitHub, it is not worth repairing it.

How to move mercurial (hg) directories to GitHub🔗

As my hg repositories were very simple (no branches, I tend to use cloned repos than branches), what I do to migrate a repository foo to github:

I used hg-fast-export
I converted the hg repo of foo to a local git repository of the same name, with the main hg branch mapped to github default main instead of the script default of master
I created an empty repository foo on github (no files such as README.md, LICENSE, ...)
I added it as origin to my local git repo
I deleted my hg repo, and git-pushed my local git repo (which became my working repo) to github. Plus I redirected the old hgweb repo urls to the new github repo adress.

I.e. as actual bash commands:

repo=foo                        # the name of the repo to convert
hg=~/hg                         # where are my local hg repos
git=~/git                       # where are my local git repos
hfe=/opt/fast-export            # where is my copy of hg-fast-export.sh
ghn=ColasNahaboo                # my name on github

mkdir $git/$repo
cd $git/$repo
git init
$hfe/hg-fast-export.sh -r "$hg/$repo" -M main -n "$git/$repo"
git branch -M main
git checkout main
git remote add origin git@github.com:$ghn/$repo.git

# Warning: for this last step, the github repo must exist and be empty
git push -u origin main

Advent of Code 2021

2021-12-07T00:00:00+00:00

I just discovered the Advent of code coding challenge. It exists since 2015, and seems really interesting in that it is language-agnostic.

Each day a problem is described, with input files consisting of numeric values for the problem. You must submit the answer which is a number by whatever means you want.

I started to do the current 2021 challenge, in bash to force myself to code in a more modern style that pass shellcheck. And later, i will probably do the other years in Go to learn it.

I publish my solutions as I code them on my github.

More info:

The advent of code (aka AOC) site
The sub-reddit /r/adventofcode to discuss AOC

Pinboard pricing model

2021-03-01T00:00:00+00:00

I am a knowledge addict, and always has been. I was reading as many books as possible, and the advent of the web has been a marvelous gift for me. But I soon realized that I needed some tools to manage this knowledge and supplement my memory. It started with pen and papers, then I used a lot the PDAs (Personal Digital Assistants) such as the fabulous Psion Series 3 and Series 5, the various smartphones, and finally the bookmarks-in-the-cloud service Delicious

But as Delicious closed, I searched a replacement, and found Pinboard, and was hooked. Not only it offered the same functionalities as Delicious (and more), but if was fast and sleek, with a minimal no-nonsense design that I favor.

It also had an original pricing system: you paid a one-time fee of $0.001 per the number of current users to get access for life. E.g $9.26 if there was already 9263 paying users and you wanted to become the 9264th. The goal was to entice people to register now rather than waiting, even though it may not have scaled. (see Pinboard.in Pricing Model: Fixing Their Math).

Alas, it could not be sustained, so in 2015 it adopted a more mainstream yearly fee scheme: $11 / year. New Pricing Policy (Pinboard Blog)

But we, old timers, kept our lifetime access we bought before the change. We were basically free-riding the new wave of customers...

Of course it could not go on, so last week, Maciej, the Pinboard author, suggested we voluntarily switch to the yearly fee scheme. And I did it gladly, Pinboard is for me a model of what web sites should be: sleek, fast, and efficient (and not re-selling your private data). At the opposite of the bloated monstrosities that a lot of sites tend to be nowadays.

Long live Pinboard!

A New version of the site for 2021

2020-12-27T00:00:00+00:00

A big change is planned for this site in 2021: I am going to abandon the Foswiki engine for it, to pursue my recent goal of going back to the web roots. Basically, it a quest that relies more on:

Fast rendering by no rendering at all: pre-compiling the site pages into static HTML+CSS+JS pages: the JAMstack approach.
What I call a LAUW approach (Linux Apache Unix-utilities Web Standards) instead of the traditional LAMP. Using the full strengths of Linux, Apache, the GNU Unix utilities, and the modern web standards (HTML5, CSS4, JS ES6) now that Internet Explorer is at last dead. This means not using software libraries (e.g: JQuery) and processors (e.g: Saas) that were designed to remedy to the poor state of some browsers.
Using Markdown for text editing
Using ultra stable and reliable technologies. I want to use things that will still work in 10 years, not the fad-of-the-day javascript framework that will be obsolete in 6 months, or that will break compatibility on each update.
Technical: And that do not try to be friendly to non-technical authors and admins, as I will be the sole admin and editor.

Now🔗

So now (December 2020), I am still using Foswiki, but progressively prototyping on it the features I will try to implement later:

A simplified skin, with all the "wiki-ism" (everything editable) removed. As you can see I got rid of the left toolbar, to keep only the top banner with its sections (Code/Surf/Blog) menu on the logo and minimal tools on the right
Editing contents in Markdown instead of the Foswiki syntax: I now do not use the Foswiki system to edit topics, but desktop-edit via marktext.
Having all the post sharing a common Form, so that the fields of this form can be easily converted to YAML as used as frontmatter (metadata) in modern Markdown-based systems.
But still using all the Foswiki power for the site admin and non-content topics (indexes,...)

The idea is to migrate progressively the contents into a form (Markdown + Frontmatter) usable in a modern static web generator like Hugo, while adapting Foswiki to use this content form, preparing a future migration.

I have developed the details of what this means in my post on the Foswiki site: Foswiki for non-wiki web sites

Spring 2021🔗

After I retire, at the end of February 2021, I will have more time to ditch Foswiki and implement the site on a new engine. It will probably be a static website generator, most probably Hugo, but maybe also Zola Eleventy, or Gasby, and incorporating ideas of the myriad of other ones.

Summer 2021🔗

I will then probably replace progressively various components of this system by ones that I will handcraft optimally to incorporate all the ideas I have been toying with during all these years: the HTML+CSS+JS layout, the tag/category system, the search engine, the comment engine, the editing process...

Later...🔗

And I may even at some time create a totally new web engine system, who knows?

Or code a wiki replacement: a collaborative editing site based on the concepts learned via this experiment.

A New Version of the site for 2020

2020-07-26T00:00:00+00:00

After 10 years of neglect, it is time for a new start of this site, because:

I am going to retire in early 2021 (in 6 months), and I will have now time to properly maintain a personal site
I am feeling the need to archive in a central place all the contents I scatter in various different places, if only for the selfish reason to be able to retreive them more easily
I was toying with the idea of going to a static web site, as it is now in vogue, and it has a kind of nostalgia for me as I started my web sites as static sites anyways. But by looking at the existing solutions, I was not convinced by them, as a lot seemed to naively solve the 80% easy part of the problem, and them struggle without any clear vision on how to solve the 20% hard part... a classic situation.

I thus decided to keep on using Foswiki (v2.1.6), as it is now quite mature, and thus stable: I like building on solid, time-tested fundations that will not change every month. And let's be honest, it is both extremely powerful and incredibly reliable. I am just tweaking it for using it as a public site (one author with all admin rights, and read-only viewers), rather than the standard wiki setup of many authors, all able to edit contents, with some able to also admin rights. My postulate is that a dynamic web site like a wiki, with proper caching, has all the advantages of a static web site, but is more practical to maintain (although more complex to implement).

I will detail my views on how to website-ize a wiki in future posts, but for now, on 2020-07-26 at noon French time, let go live!

Welcome to my (new) world!

Colas.

Usability issues on a payment form

2009-03-03T00:00:00+00:00

I know, I know, it is easy to nitpick on other people design, but this morning I tried to pay my phone bill online, and... failed. I had to retry many times, because I kept making mistakes on a simple, run-of-the-mill form to enter my credit card data. I was dumbfounded. How can, in 2009, people manage to make such a trivial and essential part of online business go so wrong? As I guess you are as curious as me, here is what I found out: (See the picture for the 3 main pain points)

1 the expiration date example is ambiguous: does 0903 here means 2009-03 or 2003-09 ? Why didnt they disambiguate it by also adding a specification (like MMYY, or, as it is a french dialog, MMAA ?)
2 but today, it was not only ambiguous but plainly misleading! As we were in March 2009, I assumed that the example was built from the current month and year. I said cool, so it is YYMM. Wrong! it was actually the reverse, MMYY, resulting in one failed attempt
3 ok, I filled the fields, and hit the OK button... and it just reset the page to empty fields! Grumbling, I re-typed the fields, re-clic, and... another blank page! After these two more failures, I tried to think (which is what you do not want your users to do, trust me). I then read the button label and discovered that this big, prominent button alone at the bottom of the page was not the Submit button but the Cancel one. I should have hit the middle one "Valider", but this button was not in the correct place on the flow of the form.

So,after 3 failed attempts, I managed to pay my bill. All this on a simple form with no fancy verification code or Captcha. Well done Telefact, I wonder if you can find a worse example still in use today.

My work on TWiki

2008-12-20T00:00:00+00:00

I discovered the wiki concept in 2000, and quickly decided that this was the future of the web site building tools, after many attempts at trying various methods of Web development. Doing some research made me choose the TWiki engine, and since then I have been part of the TWiki community, providing some work and enhancements on it. For more detailed info, the best place is to go look at my page on the TWiki site, and my personal goals for it.

Of course, since the brutal TWiki fork, I have folowed the whole TWiki community into the new great Foswiki wiki project.

I was working on: (latest first)

TWiki "koala" pattern skin A system to properly customize the pattern skin. This is the one I use on this site
Enhancements to the Vote Plugin
TWiki misc enhancements for freetown

What is good code?

2008-10-22T00:00:00+00:00

I stumbled upon the blog post "Is it important to write good code?" the other day, and became more and more ill at ease as I realized that I thought that I preferred the original code, that the author was trying to ridicule, over his new "improved" object-oriented version. At first I guessed this was another manifestation of the the "Worst is best" scenario - enhancements are often not worth the added complexity - but I realized that it was perhaps a more profound factor:

The original code is very good because it ... is small. It fits on a teminal screen, so an human being can read it at once and have less items to maintain in his short term memory and also understand it easily because it follows a natural way of thinking with sentences using IF. This becomes obvious by reading the body of the blog post surrounding the code samples, where you can see that the author is using phrases such as "if I need this I do that", showing that in plain english, the if statement is the best way to make people understand what you mean. And making code that people understand is the best way to make debuggable and maintainable code.

At this moment I noticed the citation in the blog header: "Good programmers write code that humans can understand"

Indeed :-)

PS: I know I am a bit exaggerating the issues there, and that I unfairly nitpick on Fredrik Normé, but it is that it seems to me from my personal experience that the two changes I see most in my coding efficiency as I grow older is a decrease of my short term memory capacity, and that I make more and more typos where I realize I mix up totally words with totally different meanings but that sound the same, for instance writing "never" instead of "nether", making me suspect that our natural way of thinking may be much more language-based that I imagined...

Mercurial web templating

2008-10-09T00:00:00+00:00

For some time now, I have seen the light and I switched to the new wave of the Distributed Source Control management systems. Linus famous video of his Google talk decided me to try. I was a bit apprehensive at first, wary of engaging myself on a technology that would bring more problems than solutions, but after some days of use, the realisation dawned over me: Distributed Source Control may be one little step for a programmer, but it is a giant step for programming. Why? because, its mental model actually follows your first intuitions that most of us developed as young programmers before using any source control system. Suppose you want to try a feature? instead of just copying the directory, you clone it. You mess an operation? you just remove the directory, no embarrassing traces left to keep the burning scar of shame on you for the following decades of a central repository. You are used to think of your enhancements as patches, you can work with patches. I could go on and on, but many people have done it much better than me so I'll just say that you should definitely try it.

By the way, between the 3 main contenders, git, mercurial (aka HG), and bazaar, I chose mercurial because of its simplicity, its better support of windows (I work in Linux since 1995 but my coworkers currently use Windows), and because some people at ILOG started using git so I wanted to be able to try something else. I did not choose bazaar as I wanted to stay close enough of git, to be able to switch to it if ever my dream to work in a windows-free world materializes one day...

So I started to set up a public web repository of my Open Source personal work with mercurial, which gave me a simple way to publish my work in full detail, but, although mercurial is quite easy to use, but I had a bit of trouble figuring out how to customize its look & feel.

Hgweb Mercurial template customization

2008-04-06T00:00:00+00:00

If you use the hgwebdir.cgi system to provide a web view of your mercurial repository, to customize the style like I did for (archived view), a way to do it is (in debian, paths to adapt to your linux distribution):

copy /usr/share/mercurial/templates/gitweb somewhere among your hg repositories. make a hg repository out of it
clone it to another one, e.g. myhg. This way, when upgrades will change the distributed templates, you will just have to copy the new ones in your gitweb repo, commit, and pull+merge the changes into your myhg repo.
edit the files in it: header.tmpl to add css code, etc. Adding links in the page headers will make you edit most of the files
install by copying it to /usr/share/mercurial/templates/myhg
edit your /etc/mercurial/hgrc to tell hgwebdir.cgi to use your new templates by a line style=myhg . in your [web] section. Here is my file as an exemple:

# system-wide mercurial configuration file
# See hgrc(5) for more information
[trusted]
users=colas
[web]
baseurl=https&#58;//hg.colas.nahaboo.net/
contact=colas@nahaboo.net
description=Open source software made by Colas Nahaboo
maxchanges=16
staticurl=https&#58;//hg.colas.nahaboo.net/static/
style=colas

The above will make these settings global to the site. but you can still override them on a per-repository basis by adding these lines into the hgweb.config of the repositories.
Note that you can use HTML code in the description field
This hgrc is not cloned by hg. So you must add/edit it directly on the web repository, you cannot prepare it in advance in your work dir and expect it to be pushed on the web site on first creation

The rebirth of this site

2008-04-04T00:00:00+00:00

At last, I decided myself to redo my old website, which was a collection of static html and was based on many of the various tools I made in these past years. As I grew in love with wikis over these years, the natural tought was just to do it in a Wiki, and naturally in the Wiki I like the most, TWiki. So bear with me and keep posted, as this site will slowly emerge in this first half of 2008.

Colas.Nahaboo.net - code

KXF: The Koala XML Form

KXF: The Koala XML Form

Purpose

Design

Benefits

Drawbacks

Tools

Author

My first AI-assisted pull request accepted

walkpadspeed v1: the walkpad app for geeks

What?🔗

Why?🔗

What is distinctive🔗

Why a single HTML file?🔗

Installation, Usage, and more info🔗

Bug reports: Favoring Prompt Requests over Pull Requests

What?🔗

Why?🔗

How?🔗

Why do maintainers should like it?🔗

Am I reinventing the wheel?🔗

gr: emacs-friendly grep of whole projects from anywhere

The problem🔗

The solution🔗

Emacs🔗

Custom marks🔗

Why I like it🔗

Installation, Usage, and more info🔗

ups-monitor.sh: staged shutdowns when the power goes out

The staged shutdown🔗

The config is bash🔗

Goodies🔗

Compatible UPS🔗

Installation, Usage, and more info🔗

follow-symlinks: tracing the whole link chain

What it shows🔗

The dangling links🔗

The mount points🔗

Why I like it🔗

browser-freezer: freeze the browser when the screen blanks

Why two parts? C + bash🔗

Wayland🔗

Installation, Usage, and more info🔗

passgen: a password generator with a memory

What it does🔗

The log🔗

Checking the strength🔗

Why I like it🔗

x-workspace-switcher: a menu to switch and rename X11 workspaces

Switching🔗

Renaming🔗

Why renaming needs per-WM code🔗

The Wayland question🔗

Installation, Usage, and more info🔗

License🔗

gmail-to-fastmail: keep your Gmail labels in sync on Fastmail

How it works🔗

What it does🔗

Installation, Usage, and more info🔗

Why Go?🔗

mailpixtracker: a lightweight bash CGI to track emails

How it works🔗

Features🔗

Caveats🔗

Install🔗

Fanatic of the single self-contained executable

filewebx: a simple, private, web file exchange

What it does🔗

How it works🔗

Why bash?🔗

Guest accounts🔗

Deploy🔗

What I like about it🔗

Save these Firefox tabs for later

The two scripts are:🔗

/usr/local/bin/firefox-savedtabs-restore🔗

~/.local/share/applications/firefox-savedtabs.desktop🔗

Converting Zola pages from TOML to YAML

Usage🔗