Tk
This has a name like Tk800.023. It is a CPAN module by Nick Ing-Simmons. On my very slow linux machine it took quite a while to compile the included C code, but there were no problems.

ptkdb
This is a pure perl module by Andrew E. Page. This excellent module makes it worthwhile to go the trouble of building Tk!

Both are available from CPAN.

It should work perfectly the first time! - toma

You don't need ptkdb nor X. I've debugged CGIs using the standard Perl debugger while telnet'd into the web server. Sorry, I don't have the details handy. I had to chmod the pseudo tty that telnet gave me so that the world could read/write it, then modify the CGI script to invoke the Perl debugger and tell it to use that tty as the debugging console.

I don't recall exactly what method I used to tell the Perl debugger to use an alternate tty. You can use the PERLDB_OPTS environment variables and/or the .perldb (or perldb.ini) config file but I suspect either of these will require a trick similar to:

#!/usr/bin/perl -w
use strict;
BEGIN {
    if(  @ARGV  &&  $ARGV[0] eq "-debugging"  ) {
        shift @ARGV;
    } else {
        $ENV{PERLDB_OPTS}= 'TTY=/dev/pty06';
        chdir('/home/tye/cgibin')
          or die "Can't chdir to /home/tye/cgibin: $!\n";
        exec( $^X, "-d", $0, "-debugging", @ARGV );
    }
}
[download]

I think I can see where you are headed with this, but I didn't get your example to work yet. Your idea would be especially useful on systems with firewall constraints that do not allow X Window traffic to pass from the web server to the developer's X server.

This is what I tried:
I used telnet to log onto the web server, and made a little cgi program that used your code. I set the TTY variable to be the same as the device used by my telnet window. I used chmod to open up read and write priviledges on the TTY device for the telnet window. I invoked the CGI from my web browser and I saw the prompt for the debugger come up in my telnet window. But when I typed a debugger command, the command went to the shell instead of going to the debugger. So the debugger commands weren't executed, and the CGI program hung.

Suggestions?

It should work perfectly the first time! - toma

Thanks, toma, for trying this out. You are doing great. Sorry that I forgot about this snag. With both your interactive shell and the Perl debugger trying to read from your tty, the reads will interleave and not match up well with the prompts.

So your shell wrote out a prompt and then requested a read. Next, the debugger wrote out a prompt and then requested a read. The shell's request for a read was still active and so the next line you type goes to the shell even though what you see is a debugger prompt. The debugger is still waiting for its read to complete so the CGI goes nowhere.

The simplest solution is to just tell your interactive shell to stop reading from your tty for a while. I'd usually do something like "sleep 6000". Then I could interact with the debugger fine. When done debugging that session, an interupt (usually CTRL-C) would give me back my interactive shell prompt.

A second telnet session can also be useful so you aren't tempted to try to get your interactive shell prompt back while still debugging. (:

        - tye (but my friends call me "Tye")