The Perl Debugger
This article is a tutorial about the Perl5 source debugger and assumes that the reader has written at least one or more simple Perl programs. It is best read in front of a computer, following along with a copy of the code, available at Linux Journal's FTP site (see Resources). The version of Perl that I use is perl5.004_1, which comes with the Perl debugger level 1. I've noticed some subtle differences between this and earlier versions of the debugger. If something discussed here doesn't work for you, consider upgrading.
The Perl programming language is being used increasingly on the World Wide Web as the back end to Common Gateway Interface (CGI) forms and interactive web pages, as well as for automated scripts for maintaining web sites and Unix servers in general. As a result, more and more users are beginning to learn Perl.
Conceptually, a debugger is a tool which allows the programmer a greater degree of control over the execution of the program without having to physically insert code that provides this control. A debugger allows the programmer to step through the program code, line by line if necessary. It allows peeks into the contents of the variables of the program, as well as into the stack, which is basically the list of functions (known as subroutines in Perl parlance) that have been called in order to get from the the main part of the program to the current point of execution.
There are many different debuggers. Some, such as dbx or gdb, are separate programs that can be used to debug programs written in languages such as C, C++, Modula-2 or FORTRAN. (gdb, for instance, can handle C, C++ and Modula-2, according to its man page, which on my system dates from 1991, so by now it may cover FORTRAN.) Programming environments from Borland, Microsoft and others may have debugging capabilities built into their windowing environment.
Invoking the Perl debugger is as easy as invoking Perl itself. All one needs to do is provide the -d option when invoking the Perl interpreter, like this:
perl -d perlscript.pl
Perl has also been ported to Win32 systems and can be invoked similarly. If your system supports the #! syntax for scripts, you can have this as the first line of your Perl script (assuming you keep the Perl interpreter in /usr/bin):
This option isn't supported under Win32 systems (that I know of), but there are ways to simulate it. See the appropriate documentation.
The Perl debugger can also run under Emacs, creating an integrated programming environment that is similar to products from Borland or others.
Generally, when using a program written in Perl, you are invoking the program with the Perl interpreter. A Perl compiler is on the horizon, but will not be directly covered by this article. (The most logical way to debug code intended for the Perl compiler is to use the standard debugger until the code is “bug free”, then compile it.)
Under normal conditions, the Perl interpreter will read in the Perl script and will do a certain amount of compilation, turning your Perl code into some highly-optimized instructions, which are then interpreted. When using the debugger, extra Perl code is inserted into your code before it is handed off to the interpreter. Also, a library file, called in current releases perl5db.pl, is required in your Perl script. This final script is interpreted, resulting in the program running in the debugging environment.
When programming in Perl, you should probably always use the warning flag. Use this just as you would use the debug flag, as follows:
When you are getting strange results from your program, you should definitely use the warning flag. The warning flag causes Perl to issue warnings regarding your code. These warnings are about things which are not fatal, but may cause problems. You can view the warnings as critiques of your coding style. Common warnings are those indicating that a certain variable has been used only once (perhaps a typo), or that a used package can't be found (maybe the package is not available on your system or is installed incorrectly).
Perl doesn't make you specify function prototypes and allows you to create variables at any point, so you don't have the advantages of type checking, although, with Perl 5 you can optionally have type checking for subroutines.
One Click, Universal Protection: Implementing Centralized Security Policies on Linux Systems
Join editor Bill Childers and Bit9's Paul Riegle on April 27 at 12pm Central to learn how to keep your Linux systems secure.
Free to Linux Journal readers.Register Now!
|diff -u: What's New in Kernel Development||Aug 20, 2014|
|Security Hardening with Ansible||Aug 18, 2014|
|Monitoring Android Traffic with Wireshark||Aug 14, 2014|
|IndieBox: for Gamers Who Miss Boxes!||Aug 13, 2014|
|Non-Linux FOSS: a Virtualized Cisco Infrastructure?||Aug 11, 2014|
|Linux Security Threats on the Rise||Aug 08, 2014|
- diff -u: What's New in Kernel Development
- Security Hardening with Ansible
- NSA: Linux Journal is an "extremist forum" and its readers get flagged for extra surveillance
- Monitoring Android Traffic with Wireshark
- Tech Tip: Really Simple HTTP Server with Python
- Readers' Choice Awards 2013
- RSS Feeds
- [<Megashare>] Watch Mrs Brown's Boys Movie Online Full Movie HD 2014
- Cooking with Linux - Serious Cool, Sysadmin Style!
- Senior Perl Developer