Colas.Nahaboo.net - bash

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.

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🔗

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.

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.

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

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.

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