Defining Mysterious Script Errors

[Deb]

All the browser tells me is "500 Internal Error"! I need more info then that, is there a way I can get a more specific error message?

There are two ways. They do not ALWAYS offer more info, but many times they do, as such they are worth the time to try.

1. View your script error logs located in your /logs_cgi/ directory.

2. Telnet into your account. Type:

cd /big/dom/xdomain/cgi-bin/ {Enter}
(or the path to the directory where your script is)

ls {Enter}
(this will show you a list of everything in that directory)

perl -cw scriptname.pl {Enter}
(this is a kewl little script that will let you know if the syntax of your script is ok... if not it will usually point out exactly where the syntax is flawed and suggest a fix for it)

Enjoy!

------------------
Unlocking the Power of the Internet!
www.FutureQuest.net

[Deb]

Here's another good URL for CGI Troubleshooting Tips http://webreview.com/wr/pub/98/07/31/perl/index.html

Check it out

Deb

[ChrisH]

Nice, but, why doesn't it show you how to
set the environment variables so you
can run from the command line. This is
the best debugging, I think, and you can
even run the script in the perl debugger
if you like. Hmmm, what I really
_should_ do is write a CGI that takes
its arguments and writes a shell script to
set those arguments somehow (either
environment for GET or a file for POST),
then call itself. Then you just swap this
script in for the bad script, hit it once,
then go to the command line and run the
regular cgi via the automatically
generated script. Hey, that might actually
be worth doing!

Or, if you have something written
with CGI.pm, check this:

http://stein.cshl.org/WWW/software/CGI/#debugging


ch

[Terra]

It all depends if the script uses GET or POST methods...

What I normally do is either use the CGI.pm library for the POST style scripts...

If it is GET style, I will write a subroutine call around the beginning of the file that dumps the environment to a file... I then convert that file to a bash script and tweak the variables for exactly how I want them, then the last line would call the script via 'perl -d script.pl'...

Debugging CGI scripts is an artform that requires time and patience to acquire... There is no easy way to duplicate the same environment that Apache runs the script in, versus your manual debugging invocation - but you can get mighty close...

I had the unfortunate task of learning all about CGI debugging the **hard** way, mostly by trial and error... I still have nightmares of a particularly heavy duty message forum that I worked on for a long time... (Deb, you listening???) :p

--
Terra
sysAdmin
FutureQuest

[hearts]

Terra............. i got a question.

when telnetting in, and using this info here that deb posted, or i suppose with any other task, when using the telnet that is with windows, the window is only so huge, cannot maximize its height, and what you see in that window, how do you see the info that is set forth that is above?

trying to simplify this question? HOW DO YOU SCROLL UP.. no scroll bar and the info after the command is greater than the window allows.

Is there a setting somewhere that can help with this? Or is this some kind of punishment for using the program that is from windows?

[Deb]

The HELP in Window's Telnet is short and sweet ... it contains your answer though

From the help file:

To set how many lines can be saved in the buffer

On the Terminal menu, click Preferences.
In Buffer Size, type a number between 25 and 399.

Notes

The buffer is a block of memory where the lines are stored so you can scroll up and down in the text displayed by the terminal.
If you specify more lines than will fit in available memory, Telnet sets the buffer to the largest number of lines that available memory can hold. If you specify fewer than 25 lines, Telnet reserves 25 lines

That should cover it

Deb