The Perl Debugger
There are two ways to execute the code. We know that the current line is 3 and is an if statement. The first method, s, is to step through the code, statement by statement. The other method is n, for next, which similarly steps through the code; however, in the case where the current statement is a subroutine call (as opposed to a built-in function or some sort of variable assignment), n will treat the subroutine as though it were a built-in function and will step over the subroutine, as if it is an atomic command. In contrast, s will enter the subroutine and step through every line of the subroutine. It will do the same for any subroutines encountered within the first one. This can be annoying when we know that the subroutine is working correctly—hence the n command. For this simple example, where we have no subroutines, n has the same effect as s. After entering s or n, we can simply press enter, and the debugger will reissue the last s or the last n command. This is useful to get through lines of code quickly. Pressing s displays the following:
main::(./p1.pl:7): while ($i < 10) {
Notice that we've skipped from line 3 to line 7. Enter l 3+4. This shows us four lines from line 3. We skipped to line 7 because the conditional in line 3, if(0), is false. So the then part of the conditional is ignored, and the else portion is executed.
Notice that there is a variable in the code, $i. We know that the body of the while loop will be executed until $i is greater than or equal to 10. (Enter l 7+10 to see the body of the while loop.)
So what value does $i have now? Type p $i. The print command is p, and without an argument; it will print the contents of the magic Perl variable $_. Any valid Perl expression is a valid argument to p. Because anything that the debugger doesn't recognize as a debugger command is evaluated as Perl code, you could also type print instead of p. Don't worry about having redirected standard output to something other than your screen. The debugger will take care to ensure that you'll see some output. But, typing p is quicker than typing print, and as any good programmer knows, laziness is one of the “programmer's virtues”, the other two being hubris and impatience (Larry Wall, see Resources).
Typing p $i results in nothing. No, we didn't do anything wrong. $i hasn't been set to anything, so it gets the default value of nothing. Type s (or just press enter). Try p $i again. It should print the number 1. Press enter again and type p $i again. Now, we could continue this, but we know that we will keep spinning in this while loop until the conditional returns false, which won't happen until $i is no longer less than 10. And, as I said before, impatience is another programmer's virtue, so we'll rush things along a bit. Enter $i = 8, then press enter again. Do it one more time, and we've broken free of the loop.
The last conditional checks that $i is at least equal to 9. Because it now is, the then portion of the if statement will not get executed. Note that we could have set $i back to 2 before we execute the final if statement. The result would have been an execution that under normal conditions (i.e., without using the debugger) could never have occurred (assuming the computer is working properly, and no bits in memory get fiddled).
As any good first program should, our first debug program prints Hello, World! to the screen. Notice that even under the debugger, this happens as it should. Pressing enter one more time terminates the program.
The code in Listing 2 is a more complex piece of code with a bug in it. It should print out every regular file in the current directory and all subdirectories, recursively. Right now, it only prints the files in the current directory and doesn't seem to delve into further subdirectories.
Execute this program in a directory with a few subdirectories and place files and further subdirectories in these subdirectories to create a small but diverse hierarchy.
The output of this code (once the bug gets fixed) from the directories I ran it in, looked like this:
./file1 ./dir1.0/file1 ./dir1.0/file2 ./dir1.0/file3 ./dir1.0/dir1.1/file1 ./dir1.0/dir1.1/file2 ./dir1.0/dir1.1/file3 ./dir2.0/file1 ./dir2.0/file2 ./dir2.0/file3 ./dir2.0/dir2.1/file1 ./dir2.0/dir2.1/file2 ./dir3.0/file1
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Sponsored by AMD
If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.
Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.
Sponsored by ActiveState
| Non-Linux FOSS: libnotify, OS X Style | Jun 18, 2013 |
| Containers—Not Virtual Machines—Are the Future Cloud | Jun 17, 2013 |
| Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer | Jun 12, 2013 |
| Weechat, Irssi's Little Brother | Jun 11, 2013 |
| One Tail Just Isn't Enough | Jun 07, 2013 |
| Introduction to MapReduce with Hadoop on Linux | Jun 05, 2013 |
- Containers—Not Virtual Machines—Are the Future Cloud
- Non-Linux FOSS: libnotify, OS X Style
- Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer
- RSS Feeds
- Introduction to MapReduce with Hadoop on Linux
- Validate an E-Mail Address with PHP, the Right Way
- Tech Tip: Really Simple HTTP Server with Python
- Weechat, Irssi's Little Brother
- Linux Systems Administrator
- Help with Designing or Debugging CORBA Applications
Featured Jobs
| Linux Systems Administrator | Houston and Austin, Texas | Host Gator |
| Senior Perl Developer | Austin, Texas | Host Gator |
| Technical Support Rep | Houston and Austin, Texas | Host Gator |
| UX Designer | Austin, Texas | Host Gator |
| Web & UI Developer (JavaScript & j Query) | Austin, Texas | Host Gator |
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?




7 min 57 sec ago
56 min 27 sec ago
1 hour 20 min ago
2 hours 57 min ago
2 hours 58 min ago
4 hours 51 min ago
7 hours 41 min ago
12 hours 54 min ago
12 hours 56 min ago
12 hours 57 min ago