|Do you know where your variables are?|
How to perldebug a Term::ReadLine applicationby LanX (Cardinal)
|on Dec 01, 2014 at 14:42 UTC||Need Help??|
I recently heard monks complaining that applications using Term::ReadLine can't be debugged within the perldebugger b/c it's interface relies on Term::Readline.
the trickhere one solution (at least for linux) I wanted to have documented (before I forget it again ;)
call the script you want to debug (here calc_TRL.pl ) from a shell with
PERLDB_OPTS="TTY=`tty` ReadLine=0" xterm -e perl -d ./calc_TRL.pl
and a second xterm will be opened running the program.
how it works
a second xterm is started running the debugger, but b/c of the TTY setting in PERLDB_OPTS all debugger communication goes via the parent xterm , while the calc app normally displays in the child xterm .
ReadLine=0 tells the debugger not to rely on a working Term::ReadLine.
NB: It's important that calling the second xterm blocks the execution in the first xterm till it's finished. Like this keystrokes aren interpreted by two applications in the first xterm. Just put an & at the end to see how things get messed up otherwise if the shell tries to step in.
how it looks like
becomes the front end for the debugger
as you see I get the lines from the app in the second xterm listed can set a breakpoint at the end of the loop and tell twice to continue till next breakpoint.
runs the application, I'm asked to enter a calculation which is evaluated, interupted twice by a breakpoint at line 9.
the test script
tested with Term::ReadLine::Gnu installed.
you can use this approach whenever you want the debugger communication separated into a separate term. e.g. Curses::UI comes to mind
the solution is not "perfect", of course you need to arrange the windows and switch with Alt-Tab between them. (maybe screen could solve this or an emacs inegration)
Furthermore you won't have a history with arrow navigation within the debugger, cause TRL was disabled.
another approach is to communicate via sockets with a debugger run within emacs, since emacs has it's own TRL-emulation this shouldn't interfere.
see also Re: Testing terminal programs within emacs (SOLVED) for an approach to handle all this automatically, by restarting a script with altered environment and different terminal.
Also "Pro Perl Debugging" book and various TK tools on CPAN.
(addicted to the Perl Programming Language and ☆☆☆☆ :)