Interactive debug of CGI.pm script with requests from a browser

[chrestomanci]

Greetings wise brothers

I am a fan of the perl debugger, the interactive command line one. Some people have fingers trained for Vim shortcuts, mine are trained to type x 3 $varable or b <line> $foo =~ m/bar/. My prefered method of writing perl is write a skeleton that passes perl -c and then debug it by testing out constructs in the debugger, and pasting what works into my editor.

With that in mind how should I debug a cgi script that uses CGI.pm while viewing and interacting with it using a normal web browser?

In the past I have worked on a Catalyst application, where I could run perl -d script/myapp_server.pl set breakpoints on areas of interest, and then point my browser at http://localhost:3000. When my code hit a breakpoint I could debug normaly, but at the same time I can see results as the end user does in a web browser.

I know that with CGI, you can run the script on the command line and debug it that way. The problem with that approach is that it is hard if you want to pass in a lot of form parameters, and the output you get is raw HTML.

I also know that you can do printf style debugging by running the script on a webserver, and causing it to embed lots of trace output into the page it generates.

I have also found that the EPIC IDE (a plugin for Eclipse) will let you debug cgi scripts using a built in web server. This is what I want, but without the GUI. The EPIC debugger is slow, unstable, and not as powerfull as the command line.

In short is there a perl web server out there that will run cgi scripts in the same process as the server, so that I can just run perl webServer.pl /path/to/web-root and have it execute those cgi scripts using the same perl process, while also serving up static content so that I can browse the site I am working on with a normal browser.

Thank you.

[Tanktalus]

There are a ton of pseudo-web servers on CPAN. Have you checked? There are ones like HTTP::Server::Simple, Net::Server::HTTP, and even IO::All can handle it. From these, you could simply load your code and run it. My suggestion is that you should have all of your CGI code in a module, your real .cgi script would simply be use My::CGIApp; my $app = My::CGIApp->new(); $app->run(). And your fake server would do the same: the request handler would create a new object of your app type, and run it (the "use" bit would still be needed, too, of course). This would then load your code at first (with the use), you could run it in the debugger, and break wherever (since your code is already loaded). Point your browser at localhost:$port, and you're golden.

Well, of course you'll have to handle the static content, too, but that's not too hard: check if the relative file exists, serve it. But I usually use this method just to focus on one thing at a time, not the whole site ;-)

[sundialsvc4]

There are, as they said, lots of “local web server” programs available.   For example, I am right now working on a big, hairy monster of a program that I have tamed enough to run, no longer under mod_perl, but Plack.   To test it, I can now simply run the plackup command, which is provided by Plack, and now I can access the web site at http://localhost:5000.

So, now, your CGI program is, indeed, running in a bona fide CGI-environment ... it’s just doing it within your own terminal session.   The STDERR output and so on is right there in the appropriate terminal-window.   Tools like WWW::Mechanize can communicate with this local port-number just as easily as with any other.

The only thing that doesn’t work is SSL, due to port-number issues and so forth.   But you can program your application not to require SSL when it’s running in localhost, even though it might demand to do so in production.   (plackup sets environment variables as a positive indicator of this, for example.)

[thargas]

While I agree with you about liking the perl debugger, for larger programs I prefer debugging by logging. Use a good logging mechanism like Log::Log4perl and log anything of interest. I even leave this turned on in production; it's only disk space and it allows you to debug something that happened when you weren't expecting a problem. I also wrap warn and die into Log4perl so I get warning and die messages in the log too, in context.

[i5513]

Last time I was going to write a CGI program, I was pointed to template toolkit in #perl irc channel. I recommend switching to that system (or other template based system). It made me gain many time.

I don't have any tip about debugging cgi with perl debugger. I use print STDERR / Data::Dumper for that.

[chrestomanci]

Thanks for your comment. I agree that Template Toolkit (or TT2 as it is frequently known) is nice, and for a new project I would use it, or go all the way and use Catalyst, Plack or suchlike.

The problem is that this is an old project and I can't refactor the code because I don't have a clear idea of what alot of it does. The approach I finally took was a combination of the Eclipse EPIC debugger, printf debugging to insert debug messages into the generated HTML, and the plain old perl debugger where I watch html fragments printed into my console as I debug interactively.

Brothers I thank you.