ЭЛЕКТРОННАЯ БИБЛИОТЕКА КОАПП |
Сборники Художественной, Технической, Справочной, Английской, Нормативной, Исторической, и др. литературы. |
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
.