http://qs321.pair.com?node_id=110076


in reply to Re: Debugging a CGI
in thread Debugging a CGI

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]
(though I'm not sure $^X will always be sufficient so you might have to hard-code "/usr/bin/perl" there to match your #! line.)

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

Replies are listed 'Best First'.
Re: (tye)Re: Debugging a CGI
by toma (Vicar) on Sep 05, 2001 at 11:47 UTC
    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

[reply]

      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")
[reply]
        I tried adding the sleep command and your approach worked flawlessly! I was able to single step through my CGI program and see the output get rendered a piece at a time in the web browswer.

        I should also mention that I figured out which TTY device to use running the tty command. In my case, this was pts/0. To open up the permissions on this tty I used chmod 777 /dev/pts/0, and in the cgi program the corresponding line is
        $ENV{PERLDB_OPTS} = 'TTY=/dev/pts/0';

        Using the text-based perl debugger reminded me why I like ptkdb so much! The ptkdb GUI is very intuitive, and I really have to struggle to do simple things in the text-mode debugger. This seems strange to me, since I normally don't have problems with text-based tools. I normally get bored with GUIs quickly and seek a text-based solution.

        Even so, this is a valuable technique, especially for working across firewalls. I wonder if I could also somehow use ssh?

        Thanks tye!

        Update:Changed to a better way of determining which tty to use.

        It should work perfectly the first time! - toma

[reply]
[d/l]
[select]

In Section Meditations