Colas.Nahaboo.net - linux

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.

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🔗

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

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

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.