Beefy Boxes and Bandwidth Generously Provided by pair Networks
No such thing as a small change

Easier Linux/Unix remote CGI Debugging

by Hero Zzyzzx (Curate)
on Apr 08, 2001 at 20:16 UTC ( [id://70846] : perltutorial . print w/replies, xml ) Need Help??

The things I'll discuss here are aimed at new/intermediate perl coders that know basic *nix commands: ls,cd,chmod,chgrp,mv,cp, etc., meaning I'm not going to discuss these. I also assume you can use man and understand how to use telnet/ssh to get to your server. I realize that what I discuss here isn't specific to perl (or even CGI programming with perl) but is still (IMHO) very useful. If you want to know perl tricks to ease debugging, read the other tutorials in this section.

What I am going to discuss are a few *nix tricks/commands I've found that make my life MUCH easier when I'm debugging perl CGI scripts via a command console like telnet or ssh. I'll talk a little about screen, tab file/path name auto-completion, tail, and a couple others. These commands work in bash under Redhat 6.x and Mandrake, and probably many other distros or *nix flavors.

If you want to learn more, please read the man pages for any of these commands.

  • tset: If you find that typing del, control, tab and other keys in your console just give you funny characters, type tset in the shell. tset initializes terminals, and fixes your terminal emulation in many cases to allow these keys to function properly.

  • screen: screen allows you to open multiple shell consoles in the same telnet/ssh session. I use screen as the "glue" that holds a remote debugging session together. Right after you've logged in, type screen and you'll get what looks like a blank shell prompt.

    You can work in this shell, however, you can open another shell within screen by typing Control-A followed by C, for "(C)reate." You can now cycle between the two consoles (like "alt-tabbing" in windows) by hitting Control-A followed by N, for "(N)ext."

    You can open quite a few shells and cycle through them this way. I often find that I'll tail my error logs, have code open in a command-line text editor, and have a mySQL client session logged in, all in different shells via screen.

    To kill a screen shell, just type "exit" at a prompt. You can also "detach" a screen session (which allows you to resume it later on, even in a different remote session from a different computer) by typing screen -d at a prompt. After you've detached a screen session, you can log out and get back to it at your leisure. If you're on a shared server, I wouldn't leave detached screen sessions lying around, both for security reasons and because it does take up some server resources. Your server admin might not appreciate it.

    You can "resume" your screen session by typing screen -r in the shell. Screen is very powerful and flexible, please read the man page for all it's glory.

  • Tab file/pathname auto-completion: There may be a more elegant name for this. Either way, at a shell prompt, try typing the first few letters of a filename or path and hit the tab key. The shell will auto fill the filename/path as far as it can, and if the path/shell is unique in the path you're in, it will fill it in fully. This is pretty basic, play around with it and you'll figure it out.

  • Up/down arrow: Most *nix folks know this, but hitting the up/down arrow will cycle through your most recent commands. If you get funny strings in your shell when you hit these keys, remember tset above.

  • tail: Shows the last 10 lines of a file. Using the -f option "follows" the file. So, doing tail -f /etc/httpd/logs/error_log will follow your error logs (if that's where they're located, obviously) and display the last 10 lines as things are added to the file. This is particularly useful when you're using screen above.

There are many other great unix tricks/commands that will help you in your perl coding. Hopefully the few that I've covered will be as useful to you as they are to me.

Replies are listed 'Best First'.
(jeffa) Re: Easier Linux/Unix remote CGI Debugging
by jeffa (Bishop) on Apr 09, 2001 at 17:40 UTC
    Good stuff! I just wanted to stress the importance of adding the following line to your CGI script while debugging:
    use CGI::Carp qw(fatalsToBrowser); # You are using CGI, right?
    Now all fatal errors are echoed to the browser as well as the error log file. This is a must if you can't view the web server's error log. If that is the case, then perl -cw foo.cgi is also a must.

    Also, if you find yourself on a foreign ISP's box, having to fix someone's CGI script, and there is no /etc/httpd/logs/error_log, you can find which error log file is being used by Apache by searching through [path to apache root]/conf/httpd.conf

    Apache isn't always located in /etc/httpd/. When I install Apache on a box, I always install it in /usr/local/apache/. The mileage varies. :)



      Thanks for the thoughts! Maybe I should put the locate command in here too (of course root needs to create the locate db and allow other users to access it), you can just do locate filename on many boxes to find a file (like error_log).

      The reason I didn't put in to use CGI::Carp qw(fatalsToBrowser); (something that I use all the time) was because I thought I'd focus this tutorial around *nix commands that help you with remote perl debugging/coding, and leave the perl tricks to more experienced monks.

      I thought I might be good to separate *nix tricks from perl debugging tricks in general, in an effort to make Perlmonks more non-*nix friendly.

(crazyinsomniac: more portability) Re: Easier Linux/Unix remote CGI Debugging
by crazyinsomniac (Prior) on Apr 09, 2001 at 18:04 UTC
    How about making this guide a bit more usefull. I'm sure you've seen this code before:
    BEGIN {#outputs al errors to use CGI::Carp qw(carpout); open(LOG, ">>myScript.err.log") or die "can't W 2 myScript.cgi.err.l +og: $!"; carpout(*LOG); }

    Disclaimer: Don't blame. It came from inside the void

    perl -e "$q=$_;map({chr unpack qq;H*;,$_}split(q;;,q*H*));print;$q/$q;"