Bug Hunting

Much Code, Much Work

Permanently setting new breakpoints is too much work. The save command for Python databases, gdb, and the like are not available in bashdb. To work around the problem, the debugger statements go in the shell script, which additionally makes sense because executing a script in the debugger slows things down significantly. Although this might be irrelevant for a small script, anyone who has analyzed a complete compile process will be familiar with the waits, even on fast machines.

In the first step, you need to load the bashdb-trace file. The path printed here is correct for my workstation, but may be different on yours:

source /usr/share/bashdb/bashdb-trace
function worker {
. . .
}
echo "go!"
worker
_Dbg_debugger ; : ; :
echo "end!"

The debugger is then launched by _Dbg_ debugger ; : ; :. According to the documentation, the need for the two "dead" semicolons is not quite clear, probably even to the bashdb authors.

Note in both bashdb and Eclipse that Bash scripts while running are shell scripts and remain so. If, for example, you delete a file during debugging, it cannot be recovered afterward.

Conclusions

Manual searches for problems in Bash scripts is a waste of precious time in the age of eight-core workstations. If you work with shell scripts, you will definitely want to invest some time studying the tools. With the widespread distribution of Bash, however, it is not possible to provide a complete overview of debugging in the context of a short article. For further information, you can search phrases such as shell script debugger (e.g., in Stack Overflow [6]) to find a number of discussions on various methods.

As another alternative, Microsoft's JavaScript-based Visual Studio Code development environment has gained massive support in the area of shell script programming. The plugin provided in Visual Studio Marketplace [7] supports integration with bashdb, which saves time and nerves in the presence of a GUI stack.