If you have any compile time executable statements (code within a
BEGIN
block or a
use
statement), they are not stopped by the debugger, although
require
s are.
The debugger prompt is something like this:
or even this:DB<8>
where the number in angle brackets is the command number. A csh -like history mechanism lets you access previous commands by number. For example,DB<<17>>
!17
repeats command number 17. The number of angle brackets indicates the depth of the debugger. You get more than one set of brackets, for example, if you're already at a breakpoint and then you print out the result of a function call that itself also has a breakpoint.
If you want to enter a multiline command, such as a subroutine definition with several statements, you can use a backslash to escape the newline that would normally end the debugger command:
You can maintain limited control over the Perl debugger from within your Perl script. You might do this, for example, to set an automatic breakpoint at a certain subroutine whenever a particular program is run under the debugger. SettingDB<1> sub foo { \ cont: print "fooline\n"; \ cont: } DB<2> foo fooline
$DB::single
to
1
causes execution to stop at the next statement, as though you'd used the debugger's
s
command. Setting
$DB::single
to
2
is equivalent to typing the
n
command, and the
$DB::trace
variable can be set to
1
to simulate the
t
command.
Once you are in the debugger, you can terminate the session by entering
q
or CTRL-D at the prompt. You can also restart the debugger with
R
.