Perl script suddenly gives 500 error

[Mateo1041]

Hi everyone,

We've been using a home grown Perl script for our online store for a while now. Today it suddenly stopped working after one small line change. If I revert back, it still doesn't work. The error is 500 Internal Server Error no matter what I do to it.

I've checked and permissions are fine (755). I'm also transferring in ascii mode. And the file looks just fine in a Windows text editor.

I even tried uploading the reverted version from my home laptop (had a duplicate copy) and that gives the same 500 error. But what's puzzling is it used to work a month ago when uploaded from my laptop.

What mode can I try? The code should be just fine. Would the line breaks or carriage return characters somehow have messed things up? I can email the file if anyone is curious.

Thanks for any help you can offer. This is so frustrating.

- Matt.

Blue Web Studios, LLC

http://www.BlueWebStudios.com

 

[Mateo1041]

And one more thing. The Perl file runs just fine under SSH. It's the web browser that messes it up and gives the 500 error.

Blue Web Studios, LLC

http://www.BlueWebStudios.com

 

[KevinADC]

check the server error logs and see if that helps determine the problem.

 

[Mateo1041]

My web host is having another look at it, so we'll see what happens. They'd be the only ones with access to the server error logs.

I did try the script on another server that I do have log access for, but the script still failed with the 500 error and my error log shows nothing about it. The error log I checked was: /var/log/httpd/error_log

Blue Web Studios, LLC

http://www.BlueWebStudios.com

 

[KevinADC]

add this line to your script:

use CGI::Carp qw/fatalsToBrowser/;

and see if it prints something to the browser. If you still get a 500 ISE the numbers of problems is very limited:

1. wrong shebang line
2. uploaded in binary instead of ASCII format
3. a syntax error

 

[PaulTEG]

or permissions somehow got corrupted ...

Paul
------------------------------------
Spend an hour a week on CPAN, helps cure all known programming ailments ;-)

 

[Mateo1041]

Yep, I already use the "CGI::Carp qw/fatalsToBrowser/;" line actually and my first Perl line location is just fine. But I still get fatal errors. Some CGI scripts work fine in my cgi-bin directory, just not this one. Again, if I rename an older version, it works just fine. I always upload in ASCII. There shouldn't be any syntax errors because I just changed one line and then changed it back again. The last time I uploaded the file it worked just fine.

I ended up using the old version and making a few changes to hopefully bring most of it up to speed.

How I hate Perl. It's so 90's. Can't wait to move all my remaining scripts to PHP, a far superior language with less unknowns.

Thanks for all the suggestions so far.

Blue Web Studios, LLC

http://www.BlueWebStudios.com

 

[ishnid]

How I hate Perl. It's so 90's. Can't wait to move all my remaining scripts to PHP, a far superior language with less unknowns.

Thanks for that: it's really cheered me up for the afternoon. At least, I assume you must be joking. "far superior language"?: it doesn't even support arrays!

 

[Mateo1041]

Sorry, no offense intended. I'm sure there are those who still like Perl. Whatever floats your boat. I really don't intend for this to be a Perl vs. PHP debate.

Blue Web Studios, LLC

http://www.BlueWebStudios.com

 

[Mateo1041]

It looks like the problem was with my web host and was permissions related. Here's what they had to say:

"The reason it wouldn't work in the web browser is because of the permissions. Connie had to adjust the permissions so that the default internet user could access it. When you're logged in via SSH you have more privileges and have no problem accessing it. You should be in good shape now, if you have further questions, let us know."

The file was 755, so must have been other permissions they were talking about.

Blue Web Studios, LLC

http://www.BlueWebStudios.com

 

[PaulTEG]

Ah, permissions ... really

On the "Sorry, no offense intended. I'm sure there are those who still like Perl." thing, did you check the sign on the door as you came in ... ;-)

Perl will see off (and has seen off) many young pretenders to the throne, and it's just so logical, after you get over the whole permissions thing.

On the PHP, ok permissions is one less thing to worry about, but there's a lot more than that :devileyes: <- it'll happen ;-)

Paul
------------------------------------
Spend an hour a week on CPAN, helps cure all known programming ailments ;-)

 

[Mateo1041]

So far the only real PHP issues I've run into over the past 6 years was a content-type problem, but it was more the result of a Firefox browser bug instead. Sure pulled my hair out though.

The four things that really turn me off from Perl are 1) there is no way to comment blocks that I'm aware of, 2) it isn't embedded in a regular HTML file, 3) it's restricted to a specific cgi-bin directory (on many web hosts), and 4) it has far fewer commands (PHP has much more built in without all the "use" calls).

Again, thanks everyone for your help. I'm still not exactly sure what the problem was (aside from what the host said), but I just now backed up all my Perl files server-side just in case.

Blue Web Studios, LLC

http://www.BlueWebStudios.com

 

[ishnid]

1) Yes, this is indeed a minor annoyance for people used to some other languages. There are a number of hacks to get the same effect, but it's not really commenting, as such.

2) This is a huge advantage, in many people's opinions (mine included). Separation of code and presentation is very important when developing web applications, particularly when working as part of a team with different areas of expertise. It's similar to the HTML/CSS separation of content and presentation. By using something like HTML::Template or Template::Toolkit, it's very easy to achieve this when using Perl.

3) This isn't an issue with Perl per se, rather an issue with the chosen Apache configuration of web hosts. It's quite possible to set up Apache to execute any *.pl or *.cgi file as a Perl script. They just tend not to for some reason.

4) This is also seen as an advantage by many people. Fewer commands to learn (how many sort functions does PHP have?). Plus the naming schemes for PHP functions are horribly inconsistent (verb/noun or noun/verb, underscores or no underscores).

 

[Mateo1041]

Thanks for sharing your insights, ishnid. Regarding 2), I actually use a PHP template system I developed, so the concept is similar. It's nice being able to replace templates and visual style on the fly. Almost all CMS' do similar things using PHP now in days.

I agree with you on 4) and have heard similar comments from others. I do wish their commands were more consistent across the board. Thankfully I have a good memory.

Blue Web Studios, LLC

http://www.BlueWebStudios.com