I have read most of the other post on this subject however I still cannot get the script to work. I have uploaded the files in ASCII (more than once), perl path is correct and I have set the CHMOD correctly. The files and server error log can been seen at http://nerd-network.com/dbman the script location is http://nerd-network.com/cgi-bin/dbman/db.cgi

Any suggestions would be appreciated.

Thanks.

Are you saying that you made no changes to the default files other than the path to Perl and the URL?

When ever I got that type of error it was always something simple like a mismatched bracket {} or an open quote.

That is correct the only changes made to the files were the path to Perl in db.cgi and the URL in default.cfg.

Note: I have tried both with and without a URL in the default.cfg file.

# URL of the directory dbman resides in. No Trailing Slash Please.
$db_dir_url = "http://www.nerd-network/cgi-bin/dbman";

I think maybe you missed part of the URL - the .com

also I see the URL you listed in the previous posts did not include the www.

I have changed this file so many times now everything starts to look the same. I have corrected this (.com) and still have the same issue. See updated error_log

www.nerd-network.com/dbman

Not sure what to say.

I assume you verified the path to perl with the hosting company?

Try running the script in cgi-bin and not cgi-bin/dbman as the subdirectory may not take on the properties of the cgi-bin.

go download the default files again if there is ANY chance you edited when you thought you did not.

Have you run ANY scripts in the bin or is this the first?

I'm back in the office tommorrow, got to go now.

I'm getting the "500 internal server error" which IMHO usually means a permissions setting (chmod) or directory error. This is somewhat different from the dbman's internal error (the one that says 'enable debugging to view'). Dbman's error is usually syntax related.

Hope this helps you in someway.

Try re-uploading your files and re-setting the permissions; I know, I know - you've already done that a million times but you'd be surprised how many times that one extra time makes everything magically start working.

And the best part is, you only need to get it to work once.

In my experience, there are other problems if you are on a WIN server such as a local PC being used as test box.

You might look around for posts that tell you how to check your version of Perl and confirm that it can use a .pl extension.

Use an appropriate text editor????

You need to check with your host to make sure this is the correct path to perl on your server.

#!/usr/bin/perl5

The other thing you can do in the meantime is to make certain the files are being uploaded in ASCII text mode. Premature end of script headers are most oftentimes the result of 1) uploading files in binary mode or 2) incorrect path to perl.

Hi Nerd,

I just had the same problem, and discovered the fix.
Add this line near the top of your script, and it'll work:

print "Content-type: text/html\n\n";

Allbest,
Pam (new poster)

I was just making myself CRAZY with the exact same problem.
In fact, I was *copying* working perl scripts. I was editing on notepad, uploading with acsii, setting permissions to 755.

You know what the problem was?

I didn't set me "messages" folder (where the files produced by the perl script were to live) in my wwwboard folder to 777. I set the wwwboard folder to 777, but it seems that the subfolder didn't get set!

so, if you're doing all the right things with your *.pl file (upload as ascii, chmod 755, etc) if that pl file needs to write to folder/subfolder, unless 'subfolder' is set to 777, you will see that crazymaking premature end of script message!

Hope this helps!

Thank you for your two-point summary of common errors. The scripts I was running that were causing Error 500 messages were copied from a Windows CD-ROM to a Redhat Linux 8.0 installation. I could execute them fine directly through perl 5.8.0 but would get the error under httpd-2.0.40. I had run them successfully under Windows 2000 so I knew it was a configuration error. I realized that the CR/LF's were the issue because this Windows-formatted file was loaded directly to the Linux filesystem (it didn't get translated like most ftp and similar utilities do).

I have had experience translating files/data between different computing platforms so that sent me hunting for the best way to convert the files without loading them on a windows system and then sfcp'ing them (I have found some nice windows utilities to interact with linux set to high firewall security).

I found the tofromdos utility, compiled and installed it, and ran the default flags on the script...and it WORKED!

Sounds complicated! Pleased you were able to resolve the problem. Ran into something similar with the linefeeds myself recently when uploading CF files built on IIS to a Sun server. Had me chasing my tail for a bit trying to identify the problem.

Hey durp, I just wanted to say thanks, you're reply was the one that helped me, and I know how easy it is for people who know the answers not to bother helping out, so thanks dude ;)

Hi!
I have seen that you have managed to solve that isue. Can you tell me how to do it since I have the same problem with all my perl scripts and yes I have copy the from my backup cd.

Please!!!!

Never mind, I have manage to make it work...problem was that I have used gedit to edit files instead of emacs or vi.