32. Debugging (Revision #1)

Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as
cleverly as possible, you are, by definition, not smart enough to debug it.
--Brian Kernighan

The Bash shell contains no built-in debugger, and only bare-bones debugging-specific commands and constructs. Syntax errors or outright typos in the script generate cryptic error messages that are often of no help in debugging a non-functional script.

Example 32-1. A buggy script

#!/bin/bash
# ex74.sh

# This is a buggy script.
# Where, oh where is the error?

a=37

if [$a -gt 27 ]
then
  echo $a
fi 

exit 0

Output from script:

./ex74.sh: [37: command not found

What's wrong with the above script? Hint: after the if.

Example 32-2. Missing keyword

#!/bin/bash
# missing-keyword.sh: What error message will this generate?

for a in 1 2 3
do
  echo "$a"
# done     # Required keyword 'done' commented out in line 7.

exit 0 

# === #

echo $?    # 2

Output from script:

missing-keyword.sh: line 10: syntax error: unexpected end of file

Note that the error message does not necessarily reference the line in which the error occurs, but the line where the Bash interpreter finally becomes aware of the error.

Error messages may disregard comment lines in a script when reporting the line number of a syntax error.

What if the script executes, but does not work as expected? This is the all too familiar logic error.

Example 32-3. test24: another buggy script

#!/bin/bash

#  This script is supposed to delete all filenames in current directory
#+ containing embedded spaces.
#  It doesn't work.
#  Why not?

badname=`ls | grep ' '`

# Try this:
# echo "$badname"

rm "$badname"

exit 0

Try to find out what's wrong with Example 32-3 by uncommenting the echo "$badname" line. Echo statements are useful for seeing whether what you expect is actually what you get.

In this particular case, rm "$badname" will not give the desired results because $badname should not be quoted. Placing it in quotes ensures that rm has only one argument (it will match only one filename). A partial fix is to remove to quotes from $badname and to reset $IFS to contain only a newline, IFS=$'\n'. However, there are simpler ways of going about it.

# Correct methods of deleting filenames containing spaces.
rm *\ *
rm *" "*
rm *' '*
# Thank you. S.C.

Summarizing the symptoms of a buggy script,

1. It bombs with a "syntax error" message, or
    
2. It runs, but does not work as expected (logic error).
    
3. It runs, works as expected, but has nasty side effects (logic bomb).

 Tools for debugging non-working scripts include

1. Inserting echo statements at critical points in the script to trace the variables, and otherwise give a snapshot of what is going on.
   
    Even better is an echo that echoes only when debug is on.

   ### debecho (debug-echo), by Stefano Falsetto ###
   ### Will echo passed parameters only if DEBUG is set to a value. ###
   debecho () {
     if [ ! -z "$DEBUG" ]; then
        echo "$1" >&2
        #         ^^^ to stderr
     fi
   }
   
   DEBUG=on
   Whatever=whatnot
   debecho $Whatever   # whatnot
   
   DEBUG=
   Whatever=notwhat
   debecho $Whatever   # (Will not echo.)
   

2. Using the tee filter to check processes or data flows at critical points.
3. Setting option flags -n -v -x