I have to say this:
I thought debugging would be hard... and it really isn't, (for 90%
of the cases).
The most reason I have to debug is to see what my data structures look like
and what they contain at a part in my program.
My old method was:
local $" = "\n";
print "@stuff in here\n";
etc.
but that didn't work too well with hashes, so I learned the debugger.
there are only a few commands that you REALLY need to know to do simple
debugging,
below I listed the 4 (count them FOUR) simple commands to do basic debugging
that I use most often.
Keep in mind while debugging I have a separate window with my code so I
don't use w, l or . in the debugger much.
There are several other's that are very cool, so read up on perldebug when
you get comfortable.
To start debugging use the -d option in the shebang line or on the command
line.
When debugging, the line being pointed to (or displayed) is the line ABOUT
to be run.
Here are the BASIC commands to do simple debugging:
c [line number | subroutine name ] -- without args it will continue to the
end or ^C else it will stop ONCE at that line number or the first line of
subrountine.
ie:
c 456
c mysub
b [line number | subroutine name ] [condition] -- same as c except it will
always stop there or if condition supplied will stop there when condition is
true (evaled before location only).
ie:
b 456
b mysub
b 456 $file eq "filename_to_stop_at"
p [expr] -- equivilent to perl's print except it will append a newline, and
doesn't care about the 'select'ed handle. For data sturctures use X.
ie:
p $file
p "$file $line"
X [some var] -- prints the data structure in nice format
ie:
X %GIANT_MULTIDIMENSIONAL_HASH
X @some_stuff
> -----Original Message-----
> From: David T-G [mailto:[EMAIL PROTECTED]]
> Sent: Friday, June 07, 2002 8:32 AM
> To: perl beginners
> Subject: debugging statements and such
>
>
> Hi, all --
>
> The recent post containing print statements "this is one" and so on
> reminded me of an old question that I've never had answered: what's a
> good way to trace your program as it runs, preferably without getting
> into the debugger?
>
> I realize that that's sort of a loaded question and that the
> obvious right
> answer, promoted by power perlers everywhere, is to use the debugger.
> But I don't know how to use the sucker, haven't gotten far learning it
> (and my forehead now hurts from all of the banging), and all I really
> want is the equivalent of "set -x" under sh so that I can see
> the steps
> that were taken and follow the progress in the output.
>
> I saw a clever trick where a fellow prefixed his debugging output with
> more and more '-' signs the deeper he was into subroutines
> (obviously not
> a good approach for recursion :-) but he wouldn't tell me how
> he did it.
> Bugger.
>
> Somewhere between the one side of the ubiquitous print
> statements, which
> can be difficult to clean out and pretty up when debugging is done,
> and the other side of the debugger, with all of its arcanity, is there
> a good middle ground for debugging and progress tracking?
>
>
> TIA & HAND
>
> :-D
> --
> David T-G * It's easier to fight for
> one's principles
> (play) [EMAIL PROTECTED] * than to live up to them. --
> fortune cookie
> (work) [EMAIL PROTECTED]
> http://www.justpickone.org/davidtg/ Shpx gur
> Pbzzhavpngvbaf Qrprapl Npg!
>
>
----------------------------------------------------------------------------
--------------------
The views and opinions expressed in this email message are the sender's
own, and do not necessarily represent the views and opinions of Summit
Systems Inc.
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
