http://www.perlmonks.org?node_id=1198539

ExReg has asked for the wisdom of the Perl Monks concerning the following question:

This is an issue that has been (de)bugging me lately. There are times when I have to use the Perl debugger to step through code to see where things go awry. I need to step through the code, going down into the subroutines if necessary, so I use the s command. Sure enough, I pick up a little speed and hit s on a step that has a call to some outside module, such as File::Find. I suddenly find myself outside of the code I am interested in, deep inside the File::Find module. I can hit the r to return, but I sometimes take a wrong turn there and end up coming to, groggy, in some unknown city.

My question is this: is there some way (other than driving slowly so that I can use the n judiciously) to step through code in the debugger, digging down into subroutines if needed, without fear of accidentally stepping into some use'd module? (And no, I cannot use any outside tools. Just Perl and what comes with it.)

Replies are listed 'Best First'.
Re: Driving maniacally with the debugger
by talexb (Chancellor) on Sep 01, 2017 at 17:48 UTC

    I usually pick the line number or sub-routine that I want to stop at, set a break point, then just continue (c) to that point (or to those points).

    If you actually do want to step through the code, perhaps pick spots every 10-15 lines to continue to (as in, c 451). I do know r will return from the current context, and I've used that successfully. You already know that n will just take you to the next line, stepping over (and not into) sub-routines. I'm not sure what else to suggest.

    Alex / talexb / Toronto

    Thanks PJ. We owe you so much. Groklaw -- RIP -- 2003 to 2013.

Re: Driving maniacally with the debugger
by Laurent_R (Canon) on Sep 01, 2017 at 17:54 UTC
    The best might be to use "c" with a line number to create a one-time breakpoint.

      Thanks, talexb and Laurent R, I was afraid of that. I guess I'll have to slow down on the curves since there are no guard rails. I have been using the c key more often lately for this reason, but was hoping to avoid having to program the GPS every time.

Re: Driving maniacally with the debugger
by LanX (Saint) on Sep 02, 2017 at 18:07 UTC

      Thanks. I do not know DB that well and was hoping there might be something in there I could use.

Re: Driving maniacally with the debugger
by talexb (Chancellor) on Sep 04, 2017 at 02:28 UTC

    I have another suggestion, which may or not be appropriate. In the work I'm currently doing, I have to apply a whole pile of rules to input and output records. For each decision that I make (this policy is the wrong type), I put a standardized message out to a log file. Afterwards, if I want to follow up on a particular policy, I grep for just that policy number, and I can see everything that happened to it.

    I also have the ability to run the script in a "Just process this policy" mode, rather than do everything. It still has to read through all of the input files, but it means that the data structures only have information regarding that policy, so a dump of the data structures is quick and complete. Perhaps that would be handy for your script -- specify just a single file, in order to investigate (using the debugger) exactly what's going on.

    Alex / talexb / Toronto

    Thanks PJ. We owe you so much. Groklaw -- RIP -- 2003 to 2013.

Re: Driving maniacally with the debugger
by karlgoethebier (Abbot) on Sep 02, 2017 at 12:34 UTC
    "...step through code...find myself outside of the code...Just Perl and what comes with it"

    What about the old school/poor man's approach: use constant DEBUG => 1;? Then print or say, printf, Data::Dumper or Data::Dump, Sys::Syslog bla... if DEBUG. No performance impact if DEBUG is false as far as i understood. And probably you make some poor admins happy when they are on night shift. Please feel free to correct me if i miss the point. Best regards, Karl

    «The Crux of the Biscuit is the Apostrophe»

    perl -MCrypt::CBC -E 'say Crypt::CBC->new(-key=>'kgb',-cipher=>"Blowfish")->decrypt_hex($ENV{KARL});'Help

      I have found myself using the use constant DEBUG => 1 approach frequently. My problem is that I just like to grab the keys, put the top down, and drive through the code with just occasional glances at the road signs. Just need to be a little more disciplined...

Re: Driving maniacally with the debugger
by zakame (Pilgrim) on Sep 03, 2017 at 03:25 UTC
    My question is this: is there some way (other than driving slowly so that I can use the n judiciously) to step through code in the debugger, digging down into subroutines if needed, without fear of accidentally stepping into some use'd module? (And no, I cannot use any outside tools. Just Perl and what comes with it.)

    You can probably still use DB::Skip (or just crib its code to somewhere that your ~/.perldb can find,) as it doesn't depend on anything else at all except core Perl. I've also shared a bit in Re: Debugging objects as well, feel free to crib what you need.

    For a bit of visualizing, I also use ddd to help me find where I am during the step-throughs.