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 requires 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:
DB<1> sub foo { \
cont: print "fooline\n"; \
cont: }
DB<2> foo
fooline
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. Setting $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.