source: trunk/essentials/dev-lang/perl/pod/perldebug.pod@ 3298

=head1 NAME
X<debug> X<debugger>

perldebug - Perl debugging

=head1 DESCRIPTION

First of all, have you tried using the B<-w> switch?


If you're new to the Perl debugger, you may prefer to read
L<perldebtut>, which is a tutorial introduction to the debugger .

=head1 The Perl Debugger

If you invoke Perl with the B<-d> switch, your script runs under the
Perl source debugger.  This works like an interactive Perl
environment, prompting for debugger commands that let you examine
source code, set breakpoints, get stack backtraces, change the values of
variables, etc.  This is so convenient that you often fire up
the debugger all by itself just to test out Perl constructs
interactively to see what they do.  For example:
X<-d>

    $ perl -d -e 42

In Perl, the debugger is not a separate program the way it usually is in the
typical compiled environment.  Instead, the B<-d> flag tells the compiler
to insert source information into the parse trees it's about to hand off
to the interpreter.  That means your code must first compile correctly
for the debugger to work on it.  Then when the interpreter starts up, it
preloads a special Perl library file containing the debugger.

The program will halt I<right before> the first run-time executable
statement (but see below regarding compile-time statements) and ask you
to enter a debugger command.  Contrary to popular expectations, whenever
the debugger halts and shows you a line of code, it always displays the
line it's I<about> to execute, rather than the one it has just executed.

Any command not recognized by the debugger is directly executed
(C<eval>'d) as Perl code in the current package.  (The debugger
uses the DB package for keeping its own state information.)

Note that the said C<eval> is bound by an implicit scope. As a
result any newly introduced lexical variable or any modified
capture buffer content is lost after the eval. The debugger is a
nice environment to learn Perl, but if you interactively experiment using
material which should be in the same scope, stuff it in one line.

For any text entered at the debugger prompt, leading and trailing whitespace
is first stripped before further processing.  If a debugger command
coincides with some function in your own program, merely precede the
function with something that doesn't look like a debugger command, such
as a leading C<;> or perhaps a C<+>, or by wrapping it with parentheses
or braces.

=head2 Debugger Commands

The debugger understands the following commands:

=over 12

=item h
X<debugger command, h>

Prints out a summary help message

=item h [command]

Prints out a help message for the given debugger command.

=item h h

The special argument of C<h h> produces the entire help page, which is quite long.

If the output of the C<h h> command (or any command, for that matter) scrolls
past your screen, precede the command with a leading pipe symbol so
that it's run through your pager, as in

    DB> |h h

You may change the pager which is used via C<o pager=...> command.


=item p expr
X<debugger command, p>

Same as C<print {$DB::OUT} expr> in the current package.  In particular,
because this is just Perl's own C<print> function, this means that nested
data structures and objects are not dumped, unlike with the C<x> command.

The C<DB::OUT> filehandle is opened to F</dev/tty>, regardless of
where STDOUT may be redirected to.

=item x [maxdepth] expr
X<debugger command, x>

Evaluates its expression in list context and dumps out the result in a
pretty-printed fashion.  Nested data structures are printed out
recursively, unlike the real C<print> function in Perl.  When dumping
hashes, you'll probably prefer 'x \%h' rather than 'x %h'.
See L<Dumpvalue> if you'd like to do this yourself.

The output format is governed by multiple options described under
L<"Configurable Options">.