osh is a new shell that aims to be a drop-in replacement for bash. To reach that goal it is important osh matches bash’s behavior in almost every case. osh however, did not have a kill builtin, which is of course a problem for compatibility. So I set out to work on a kill implementation. And doing this made me realize you can not just rely on the --help output of a command to figure out what it does. ...
Introduction osh is a new shell that is intended to be an upgrade path from bash (and similar shells) to a better language and runtime. We’re trying to prove osh is mature enough to be the only shell a distro needs. We are doing this by building all the packages in the Alpine distro, using osh as the only shell on the system. If we see a package fails to build with osh, we try to figure out why it doesn’t build with osh but does with ash (the default shell on alpine) and bash (explicitly used by some scripts). Since we are down to the last issues, the disagreements between osh and ash (and bash) are often subtle. Figuring out what the disagreement exactly is that causes the package build to fail is often quite a journey. In this post I’d like to show what a particular journey looked like, and hopefully show some useful shell debugging tips along the way. ...
Tracking down differences between OSH and other shells The setup We’re testing if osh (an alternative shell) can build all Alpine Linux packages by replacing /bin/sh and /bin/bash with symlinks to osh. We build the packages in our “custom” osh environment, and in a “regular” environment (referred to as baseline). There is a build server that builds all packages and reports if there is a disagreement between baseline and osh, i.e. a package can be built in the baseline environment but when we use osh in place of ash and bash the build fails. This gives us a nice overview of what packages we should investigate, and it also provides us with a mechanism to track the causes of the build failures. If we notice a package failed to build we can use the same set up on our local machines to debug the individual package further. The end goal is to end up with as little disagreements as possible. ...
Below is a list of useful snippets I took from the GDB manual to reference later. Print exceptions: p $_exception Define a function to rebuild a program from within gdb define reload set confirm off shell make file ./your_app run end Run with catch throw and without initial breakpoint: gdb -ex "catch throw" -ex "run" --args To look at some context, we can display ten lines of source surrounding the current line with the l (list) command. ...
I have started to work on a new small Zig project. The application has 2 tasks it has to perform. It has to listen for incoming HTTP requests and handle them, and it also has to periodically check if it has to message me a reminder I scheduled for myself through a Telegram bot. I just wanted to get something working quickly, so for handling incoming HTTP requests I used Zig’s std.http.Server struct. This worked fine enough, I had it in a loop like this to wait for incoming requests: ...
Recently I ran into some issues with a C++ application I was working on. The official Linux distribution we supported for the application is Ubuntu 20.4. This version of Ubuntu is pretty outdated now a days, and is even nearing its EoL date. On my development machine I prefer to run the latest LTS version. Building the application in a newer Ubuntu version (f.e. 24.4) however, produced a binary that would instantly crash on the officially supported platform. Not only that was an issue though. If I were to send a build of the application that happened to be built in Debug mode to a colleague, the application also crashed instantly, even though it worked fine on my machine. The reason for this: shared libraries. ...
Link-time substitution is one of three methods to create test doubles for your project. Test doubles are used to replace pieces of code that your software depends on (the code under test, or CUT), but that are hard to use in combination with (automated) tests like unit tests. For software developers the most difficult type of code to test will probably be code that is hardware dependent. Without test doubles, it is not possible to unit test how your CUT responds to, for example, a temperature sensor that outputs different temperatures, or a sensor that breaks while the application is running. ...