At 01:15 PM 6/22/02 -0500, David T-G wrote: >Peter -- > >...and then Peter Scott said... >% >% At 09:37 AM 6/22/02 -0700, drieux wrote: >... >% >that is in essence the Shell Debugger. >% > >% >Which really is not a 'realDebugger[tm]' because it really >... >% >% Eh? The n and s commands do exactly that. See also the r command. > >He didn't mean the perl debgger; he meant sh -x :-)
Oops; somehow I read "Shell" as "Perl". >% >% Sounded like the original poster wanted tracing. The t command in the >% debugger does that. > >I agree, and I want that, too. I'm going to have to check out 't'. > > >% >% Tracing isn't generally as useful for a Perl script as for a shell >% script because a shell script typically executes far fewer statements >% than the average Perl script. So the output can be unreasonably verbose. > >Yeah. What we really want is a command or flag that does exactly what -x >does :-) I forget whether or not -x stays on when you jump into a function, Would you like tracing that goes off when you go into a function? Suppose if you gave a numeric argument to 't' it would trace up to that depth in subroutine calls beneath the current level but not beneath? That might be doable (as a patch to the debugger). >but it would be nice to be able to watch perl do its thing and how it sees >the vars that it's testing (in sh you get to see > > [ true = true ] > >when you wrote > > [ $var = true ] > >in your script). Not really feasible for anything except simple scalars... that's good enough for the shell, but Perl goes much further. -- Peter Scott Pacific Systems Design Technologies http://www.perldebugged.com/ -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
