Contents:
Tips for Debugging Shell Scripts 
Quoting Trouble?  Think, Then Use echo 
Bourne Shell Debugger Shows a Shell Variable 
Stop Syntax Errors in Numeric Tests 
Stop Syntax Errors in String Tests 
Watch Out for Bourne Shell -e Bug 
Quoting and Command-Line Parameters 
Test Built-In Commands for Failure 
If Command Doesn't Return a Status, Test the Error Messages
A Portable echo Command 
Depending on the Bourne shell version you have, the error messages it gives can be downright useless. For instance, it can just say 
End
 
of
 
file
 
unexpected
. Here are a few tricks to use to get a little more information about what's going on.
Start your script like this:
#!/bin/sh -xv
(or, if your UNIX can't handle 
#!
, use the command 
set -xv
 (
44.19
)
). The 
-xv
 shows you what's happening as the shell reads your script. The lines of the script will be shown as the shell reads them. The shell shows each command it executes with a plus sign (
+
) before the command.
Note that the shell reads an entire loop ( for , while , etc.) before it executes any commands in the loop.
If you want to run a script with debugging but you don't want to edit the script file, you can also start the shell explicitly from the command line and give the options there:
%sh -xvscrfile
Debugging output is usually pretty long, more than a screenful. So I pipe it to a pager like 
pg
. But the shell sends its debugging output to 
stderr
, so I 
pipe both 
stdout
 and 
stderr
 (
13.4
)
. Using a pager has another advantage: if you want to kill the script before it finishes, just use the pager's "quit" command (like 
q
).
 When the pager quits, UNIX may even kill  the shell script (you may see the message 
Broken pipe
 (
50.12
)
).
Do you want to save the debugging output in a file and see it on your screen, too? Use tee ( 13.9 ) to snag the scrfile stdout and stderr; add tee to the pipeline before the pager.
If the script is slow, you can run it in the background. Redirect the shell's output and errors ( 13.5 , 8.13 ) into a temporary file ( 21.3 ) . Use tail -f ( 25.16 ) to "watch" the log file. If you want to do something else while the script runs, just kill the tail command (with CTRL-c or your interrupt key), do something else, then start another tail -f when you want to watch again.
Finally, if the script normally writes something to its standard output, you can split the normal and debugging outputs into two files ( 13.1 ) .
If the shell says 
End
 
of
 
file
 
unexpected
, look for a line in your script that has an opening quote but no closing quote. The shell is probably searching for but never finding the matching quote. The same goes for missing parentheses and braces (
{}
).
If you're getting an 
End
 
of
 
file
 
unexpected
 error, put these two lines near the middle of the script:
echo "DEBUG: quitting early..." 1>&2 exit
Then run your script. Those lines will print a message and stop the shell where you put them. If you don't get the 
End
 
of
 
file
 
unexpected
 error anymore, you know that the problem is somewhere after the 
exit
 line. Move those two lines farther down and try again. (Otherwise, move them up...)
A message like 
line
 
23:
 
;;
 
unexpected
 means that you have an unmatched piece of code somewhere before line 23. You'll also see 
fi unexpected
. Look at all nested 
if
 and 
case
 statements, and statements like them, to be sure that they end in the right places.
The shell may give you an error that mentions "line 1" or another line number that seems way too small, when there's no error close to the top of your script. Look at any loops or other structures with redirected inputs or outputs ( 45.22 ) . Some Bourne shells start a separate shell to run these loops and lose track of the line numbers.
-