The Perl Debugger
Many people use the Perl debugger with no more than these commands. Once you are comfortable with those, however, an additional four commands can make your debugging more efficient, especially for programs that use object-oriented code:
/<pattern>: lists source code at next regular expression match.
?<pattern>: lists source code at previous regular expression match.
S: lists all subroutines and methods available to the program.
m <object or package>: lists all methods available on the given object or package.
You can search and display code that matches a string or regular expression with / for forward searches and ? for backward searches. There should be no space before the string you're looking for:
DB<6> /name 6: my $name = "Pengu";
The S and m commands are useful for exploring what subroutines or methods are available: S lists every subroutine and method available to the program. These are in reverse order of when they were loaded by use or require, and they include routines loaded from the debugger, such as Term::ReadLine. The m command lists every method available to an object or by way of a package. Here is a sample:
DB<7> use CGI DB<8> $q = new CGI DB<9> m $q AUTOLOAD DESTROY XHTML_DTD _compile _make_tag_func _reset_globals _setup_symbols add_parameter all_parameters [...]
Actions, breakpoints and watchpoints provide even more control over the debugger and the running program. You may prefer using them from a graphical Perl debugging front end, such as ddd, ptkdb or Activestate Komodo. The most common complaint about the Perl debugger is remembering the proper command-line shortcut for each command, and these commands add still more shortcuts to remember.
Additionally, in Perl 5.8 some of the keyboard commands have changed to make them more internally consistent. Often, though, people need to use both 5.8 and an earlier version, so it may be easier to use a GUI. I describe the commands from the command line below; the principles remain the same.
An action is used to wedge code into your program without modifying the source file. It can be useful when the code is in production and you want to test a change. It's also useful if you're in the middle of a debugging run and want to change code without restarting the debugging session from scratch.
You set an action like so, a <line-number> <code>. An example could be:
DB<10> a 9 $index = $_;
This adds a new command inside the foreach loop that stores the index count, which is incremented each time through. If you list the program, you see an a next to the line number that has the action. The action is executed before the line to which it is attached. You can list actions you've set with L and delete an action by specifying a with the line number without a command. The previous is for Perl 5.6 and earlier; in Perl 5.8, delete an action with A and the line number of the action.
Breakpoints and watchpoints return control to the debugger from continuous execution, such as from r and c described above. They are useful for jumping ahead to the particular iteration of a loop that is having problems, without repeatedly stepping through the loop by hand.
A breakpoint is set on a line number or subroutine, with an optional condition that must be met. A breakpoint is set with b as shown here:
If you list the program, you can see a b next to the line number at the first line of the subroutine shout. Press C to continue execution, and it stops inside the subroutine.
If you followed the previous example and set the action on line 9, you could set a breakpoint to stop on a particular iteration of this loop:
b shout ($index eq 8)
This should give you an idea of the power of actions and breakpoints, if you imagine debugging a longer program with complex conditional statements and external data sources.
You can list breakpoints with L and delete one with d in Perl 5.6 and earlier. In Perl 5.8, you delete a breakpoint with B.
A watchpoint probably is better known as a watch expression. It halts the program as soon as a specified expression changes. In Perl 5.6, it is set with W as shown here:
You can list watchpoints with L and delete all of them by specifying no parameter to W. In Perl 5.8, add a watchpoint with w and delete it with W.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Doing for User Space What We Did for Kernel Space
- Tech Tip: Really Simple HTTP Server with Python
- SuperTuxKart 0.9.2 Released
- Parsing an RSS News Feed with a Bash Script
- Rogue Wave Software's Zend Server
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide