May the source be with you, but remember the KISS principle ;-)
Home Switchboard Unix Administration Red Hat TCP/IP Networks Neoliberalism Toxic Managers
(slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and  bastardization of classic Unix

Perl Debugging Tips


Debugging Perl Scripts

Recommended Books Recommended Links

Perl Style


Cheat sheets

Perl Debugger Stepping Commands Viewing variables from Perl debugger Perl Debugger Breakpoint Commands Viewing the Perl code during script execution Perl Error Checklist Perl debugging Tips
Perl POD documentation Perl Xref Regular expressions Debugging regular expressions Perl Programming Environment    
Debugging Software Testing Program understanding Pretty Printing Perl Tips Humor Etc

While a good debugger greatly increases the value of the language, the debugger is just a part of Perl Programming Environment. It does not replace a good editor, database of typical Perl errors, lint, prettyprinter and other important part of Perl programming environment. In a way this is a the "last resort" to find a particular bug in the program.

The problem with command line debuggers is that you need to remember set of commands to use it productively. It is not an easy task especially if you do not use debugger daily. One obligatory thing to do is to print a cheat-sheet and put it above your monitor. I for example noticed that from one debugging session to another I forget even some essential commands.

If you think that because I wrote this page I use all the commends discussed you are deeply mistaken. I use a very primitive subset close to the minimal set described below. And what is interesting any my attempts to use a richer subset fail -- from one episode during which I can benefit from this additional functionality to another I completely forget how to use it.

A typical person probably is not able to remember more then seven Perl debugger commands. In this sense I am a typical person although it is more correctly to say not seven commands but seven groups of similar command as brain works in hierarchical chunks.  I typically use just the following seven commands:

  1. n -- single step without stepping into subroutines. You need to enter it only the first time. After that pressing Enter will repeat the command.
  2. s -- single step with stepping into subroutines. This is an alternative command to n and it is useful if you need to look how a particular subroutine behaves on the text data.
  3. c -- continue processing until a break of some sort.  In the simplest (and most useful) case a line number can serve as one time (temporary) breakpoint, for example:
    c 200
  4. l min+incr -- displays  "window" of the program's code of incr lines. Without parameters defaults to 10 lines window from the last executed line. Repeat of command without parameters bring the next ten lines and so on.  With two parameters shown lists incr+1 lines of the script starting at min.
  5. p -- a regular Perl print command, so you can use the normal Perl syntax there, for example:
    p "$ARGV[0]\n$_";
  6. ! number  -- Redo a previous command (without number defaults to the previous command). Perl debugger numbers debugger commands in its prompt so scrolling back you can see what command that you entered needs to be repeated.
  7. H -- lists the debugger commands history. First of all it can serve as an alternative to scrolling back. This way you will see commands that you already entered in this session. You can limit output by providing a number prefixed with a minus sign. For example:
    H -5
    it will displays the last 5 commands. Only commands longer than one character are stored in the history. (s or n, are omitted from history).

See more at Debugging Perl Scripts. A good free introduction to Perl debugger can be found in perldebtut -

Best Perl debugger tips

You can execute any external command in the debugger using !! command

This debugger command runs the external command in a subprocess, which will read from DB::IN and write to DB::OUT. Shell used is the shell defined in $ENV{SHELL} external variable

To look at a "window" of source code around the breakpoint, use the w command:

DB<2> w
5     }
7       sub infested {
8==>b       my $bugs = int rand(3);
9:          our $Master;
10:         contaminate($Master);
11:         warn "needs wash"
12              if $Master && $Master->isa("Human");
14:         print "got $bugs\n";

As you see by the ==> marker, your current line is line 8, and by the b there, you know it has a breakpoint on it. If you'` had set an action, there also would also have been an a there. The line numbers with colons are breakable; the rest are not.

Command c can be used with line number.

In this case the debugger will run the script to this temporary breakpoint and switch to interactive mode. For example c 200 will run script till the line 200 or to the end if the line 200 is not executed on particular data.

Switching to step-by-step execution dynamically from within the program

You can switch to step-by-step execution using Perl debugger from within your Perl program itself. to transfer control back to the debugger use the following statement, which is harmless if the debugger is not running:

$DB::single = 1;
If you set $DB::single to 2, it's equivalent to the n command, whereas a value of 1 emulates the s command.

The $DB::trace variable should be set to 1 to simulate the t command.

To enter Perl debugger without supplying a program and use execution "on the fly"

To enter the debugger without supplying a program, supply the -e option with the -d option:

perl -de 1
This line starts the debugger with a "program" consisting of the single statement
(which is just a dummy statement). Starting the debugger this way enables you to try small tests interactively and examine the system variables resulting from their execution. Very useful for debugging regular expressions.

Any debugger command output can be piped via external program using pipe symbol like in shell.

Write down watches for the program in a special file that you can preload staring the debugger or load any time with the source statement. You can also define an aliases for useful but long command (especially p commands) in the same file so that the next session you do not need to retype them.

If the output of a debugger built-in command scrolls past your screen, just precede the command with a leading pipe symbol so it's run through your pager. For example:


Top Visited
Past week
Past month


Old News ;-)

Debugging Tips

The goal is pretty simple: you want your code to work. The current state of affairs is also pretty simple: it ain't working. This note is all about how to get from where you are to where you want to be. In PHENIX, we have all sorts of code. There are interpreted scripts in shell, perl and ROOT macros. There are programs compiled from C, C++ and Fortran source code. There are standalone programs. There are shared libraries. And there are dynamically loaded shared libraries. It's quite a zoo and figuring out what you should do to diagnose the source of a problem when something isn't working properly can be a bit daunting.

I recently gave a presentation about debugging in PHENIX.

Before I start describing specific techniques for debugging code, here is some more general advice.

The long-time favored refuge of those who don't know how to use better techniques. I hope this note will help you learn a few of these better techniques and make the practice of embedding print statements in your code a thing of the past. Is there a place for the print statement in the armamentarium of the serious debugger? Well, yes, but those places are few and far between. Depending on the environment in which you're working, a print statement may be the most sophisticated option at your disposal for debugging distributed programs like those built on top of MPI (message passing interface). It might be your only option if you're debugging code running on stripped down embedded processors.

You're not debugging code under those conditions. Stop using print statements to debug your code.

Script tracing

What's a script? Roughly speaking, it's a piece of code that gets fed to an interpreter whenever you want to use it. It's not quite that simple in real life, but that'll do for now. We have lots of scripting languages. Shell scripts, perl scripts, and ROOT macros are all scripts. There are a few good techniques for debugging scripts. One of the easiest is tracing.

Tracing means telling the interpreter that's handling the script to print out each line of the script before it executes it. The output of the script also gets printed, so you end up with a log of source lines intertwined with script output. It's a bit like embedding a print statement before each and every line of your script. It can result in a lot of undigested information, and sometimes that's enough to track down the reason your script isn't working the way you thought it was supposed to. Tracing, like embedding pring statements, has the downside that it's not very flexible; you're just a passive observer as your script runs and spews its output to the screen. You can't control your program. You can't change the values of any variables. You can' do much of anything excpet watch. But sometimes that's enough.

Tracing shell scripts

Shell scripts are very useful. They must be useful since they come in such a variety of flavors. Among the choices you have are sh, csh, tcsh, ksh, zsh and ash scripts. They're all similar, yet quirkily different. Most of the scripts you'll encounter (or write) will be sh or tcsh scripts. You can turn on tracing for these type of scripts (and for some of the others also) by adding the command option "-xv" to the command line of the appropriate interpreter. For instance, suppose you have a tcsh script called dpm.csh that contains the following lines:
foreach n (5 2 1 0)
 @ i = 10 / $n   
 echo $i

If you run this straight away, you should see this:

% tcsh dpm.csh
Division by 0.

OK, there's a bug in the code (but then you knew that). Let's turn on tracing and see if it helps us narrow things down. Do it like this:

% tcsh -xv dpm.csh
foreach n ( 5 2 1 0 )
@ i = 10 / 5
echo 2
@ i = 10 / 2
echo 5
@ i = 10 / 1
echo 10
@ i = 10 / 0
Division by 0.

At least you can see what the script was planning on doing before it actually did it. You can see the line where the division by zero is being performed, followed by the line which prints an error message to the screen. This is such a simple example that the tracing doesn't really add much, but you should know how to do it. It can help for much more complicated scripts.

Tracing perl scripts

There are similar techniques available for tracing a perl script. Suppose you had a similarly simple perl script called that contained the following lines:
foreach $n (5, 2, 1, 0)
    $i = 10 / $n;
    print "$i\n";

Pretty much the same thing as the shell script above. Run it and it produces pretty much the same output too.

% perl
Illegal division by zero at line 2. 

To trace this script, run it under the perl debugger (by adding the "-d" command line option). At the debugger prompt, type the command "t" to turn on tracing. Follow that with "r" to run the script and you'll get the tracing output you're looking for. Type "q" to quit the debugger. Like this:

% perl -d
Default die handler restored.

Loading DB routines from version 1.07
Editor support available.

Enter h or `h h' for help, or `man perldebug' for more help.

main::(	foreach $n (5,2,1,0) {
  DB<1> t
Trace = on
  DB<1> r
main::(	 $i = 10 / $n;
main::(	 print "$i\n";
main::(	foreach $n (5,2,1,0) {
main::(	 $i = 10 / $n;
main::(	 print "$i\n";
main::(	foreach $n (5,2,1,0) {
main::(	 $i = 10 / $n;
main::(	 print "$i\n";
main::(	foreach $n (5,2,1,0) {
main::(	 $i = 10 / $n;
Illegal division by zero at line 2, <IN> line 2.
Debugged program terminated.  Use q to quit or R to restart,
  use O inhibit_exit to avoid stopping after program termination,
  h q, h R or h O to get additional info.  
  DB<1> q

It may look a bit wordy, but it's very much the same thing as you could see when you traced the shell script. It helps you localize the error (it's got something to do with line 2) and that can be very useful in tracking down the cause of the problem.

Recommended Links

Google matched content

Softpanorama Recommended

Top articles


Perl Debugger Tutorial 10 Easy Steps to Debug Perl Program



Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy


War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotesSomerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose BierceBernard Shaw : Mark Twain Quotes


Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law


Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOSProgramming Languages History : PL/1 : Simula 67 : C : History of GCC developmentScripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-MonthHow to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Haterís Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

Copyright © 1996-2021 by Softpanorama Society. was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.

This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...

You can use PayPal to to buy a cup of coffee for authors of this site


The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: March, 12, 2019