Tech News
← Back to articles

Colodebug: A simple way to improve bash script debugging (2021)

read original related products more articles

COLODEBUG: a simple way to improve bash script debugging

In this article, I will show you an easy-to-use, simple, and non-disruptive way to extend a GNU bash script by a few lines that can help make sense of its execution flow at runtime a fair bit easier. Using this method will also allow you to effortlessly add a “verbose” execution mode to scripts you create or extend. It also improves the usefulness of set -x aka xtrace mode. The method is compatible with zsh, and maybe also other advanced Bourne-style shells.

POSIX sh will, unfortunately, only work in a limited manner, as implementing COLODEBUG support involves using/redefining a function name that at least the implementations I checked did not support. Basic colon comments in xtrace mode, however, will work under full POSIX compliance, too.

If you do not feel like reading copious amounts of prose where I get to try to be funny, you may want to skip to the tl;dr-style section at the very end of this article to get to the gist of it all.

Debugging shell scripts - a few common approaches

Usually, when something in your unfortunately-by-now-much-too-elaborate bash script goes wrong, there’s a few tricks to ease the burden of debugging it: Sprinkling a few echo (or, better yet, printf ) calls all over, making it sleep , read or exit at neuralgic points, or enabling xtrace mode (via set -x ) to get glimpses at what the interpreter is doing piling up on stderr. The latter is often especially helpful, but has one characteristic that makes it harder than necessary to grok what is going on at times, especially with long scripts that you did not write yourself (or that you do not have any recollection of writing): It simply hides some tricky business, such as common redirection ( < , > , etc.) operations, and it does not reproduce any comments the interpreter encounters in the script’s source.

I suppose software developers do not universally agree on many things, but most will like helpful comments in code they have to understand much better than their absence. I always lamented it as a peculiar kind of shame that, when dealing with Bourne-style shell scripts, one is limited to enjoying these “at rest” only, preferably displayed by your favorite standard editor, ed(1). So how about we try tricking the shell into also providing us with comment-infused context information at runtime, at least in the more tricky corners of the contraptions we and our fellow shell artisans dare create?

Introducing: :

Luckily, our wise forebears that graced us with UNIX, POSIX, and the Bourne-compatible shell, granted us to enjoy one particular powerhouse of a command that is : . Consulting bash ’s excellent online help system, we can quickly grasp wherein lie its many virtues:

$ help : :: : Null command. No effect; the command does nothing. Exit Status: Always succeeds.

... continue reading