home | O'Reilly's CD bookshelfs | FreeBSD | Linux | Cisco | Cisco Exam  

Perl in a Nutshell

Perl in a NutshellSearch this book
Previous: 5.2 Perl Functions in Alphabetical Order Chapter 6 Next: 6.2 Debugger Commands

6. Debugging

Of course everyone writes perfect code on the first try, but on those rare occasions when something goes wrong and you're having trouble with your Perl script, there are several things you can try:

  • Run the script with the -w switch, which prints warnings about possible problems in your code.

  • Use the Perl debugger.

  • Use another debugger, or a profiler such as the Devel::DProf module.

The major focus of this chapter is the Perl debugger, which provides an interactive Perl environment. The chapter also describes the use of the DProf module and the dprofpp program that comes with it; together they can provide you with a profile of your Perl script. If you've ever used any debugger, and you understand concepts such as breakpoints and backtraces, you'll have no trouble learning to use the Perl debugger. Even if you haven't used another debugger, the command descriptions and some experimenting should get you going.

6.1 The Perl Debugger

To run your script under the Perl source debugger, invoke Perl with the -d switch:

perl -d myprogram
This works like an interactive Perl environment, prompting for debugger commands that let you examine source code, set breakpoints, get stack backtraces, change the values of variables, etc. If your program takes any switches or arguments, you must include them in the command:
perl -d myprogram myinput
In Perl, the debugger is not a separate program as it is in the typical compiled environment. Instead, the -d flag tells the compiler to insert source information into the parse trees it's about to hand off to the interpreter. That means your code must first compile correctly for the debugger to work on it - the debugger won't run until you have fixed all compiler errors.

After your code has compiled, and the debugger has started up, the program halts right before the first runtime executable statement (but see Section 6.3, "Using the Debugger " below regarding compile time statements) and waits for you to enter a debugger command. Whenever the debugger halts and shows you a line of code, it always displays the line it's about to execute, rather than the one it has just executed.

Any command not recognized by the debugger is directly executed as Perl code in the current package. In order to be recognized by the debugger, the command must start at the beginning of the line, otherwise the debugger assumes it's for Perl.