Unknown Perl script error

Hello coleagues,

While moving a website to Dreamhost, I encountered an unexpected problem with Perl scripts.

It seems the parsing of an HTML post request in a Perl script is triggering an error that I cannot figure out.

To test it, I wrote a simple script, which runs without a probblem, as long as it doesn't have an HTML post request. When it does, such as script.cgi?dir=/units&pointer=0 it gives an error at the command line that says it cannot find the file, but at the error log, it says that it cannot open the log, followed by an error for fopen, saying that it cannot open the file because of "not authorized"

The thing is that I do not have any fopen function in the script. Where is this error message coming from? Is it trying to post the request somewhere, in some log that it cannot open? It does post to the error log.

Has anyone have this happen before?

TIA for your help.

Eagle

Eagle
Florida, USA
"If you think you can or if you think you can't, you 
are right"

It sounds very much like it is permissions related. DreamHost uses suEXEC, so it is *your* user that the script sis running as. Your should have both the directory the script is running in, *and* the script itself set to 755. Could this be part of the problem?

Also, Have you experimented with using a different representation of the path (complete absolute path to file, etc.)? While you certainly don't want to do this for a"production" site, it can sometimes help with the debugging.

--rlparker

Hello Parker:

Thank you for responding.

I don't see how it could be permissions related and run from the command line without a post request. The permissions are 755 for both the directory and script.

Look, I put a simple test script like this:
#!/usr/bin/perl
use strict;
use warnings;
print "Content-type: text/plainnn";
my $string=<STDIN>;
print $string . " is the post requestn";

If you execute this script from the browser, even without a post request, it gives you a 500 error.

If you run it without a post or get request from the command line, it will run and print:

Content-type: text/plain

perl test.cgi
(I don't understand why it prints the command)

It waits for an input and then, if you press <Enter>, it prints:
is the post request


But... if you execute it from the command line like this:
perl test.cgi?test

It will tell you at the command line:
Can't open Perl script "test.cgi?test": No such file or directory

It will tell you at the error log:
Failed to open log file
fopen: Permission Denied

but it will not tell you where was the fopen function executed at.

Then I changed the script to:
#!/usr/bin/perl
use strict;
use warnings;
print "Content-type: text/plainnn";
my $string=$ENV{QUERY_STRING};
print $string . " is the post requestn";

with similar results.

A Perl CGI script cannot get much simpler than that. It mus be some server configuration I am not aware of or that is malfunctioning.

I have already spent way too much time on this and gotten nowhere. I certainly hope someone who has been through this before can point me in the right direction.

I wrote to customer support, but so far no help.

TIA,

Eagle

Eagle
Florida, USA
"If you think you can or if you think you can't, you 
are right"

In reply to:

---

But... if you execute it from the command line like this:
perl test.cgi?test

It will tell you at the command line:
Can't open Perl script "test.cgi?test": No such file or directory

---

Red herring. You should know that the perl executable expects the argument to be the path name of a file. Yet there you are trying to pass it a URL instead! That's OK, we all know you meant to say:

  set QUERY_STRING=test
  perl test.cgi

In reply to:

---

A Perl CGI script cannot get much simpler than that. It mus be some server configuration I am not aware of or that is malfunctioning.

---

Don't forget to check your .htaccess files, if any. And try turning off "Web Security" from the Web Admin Panel for the domain.




openvein.org -//-

After wasting many hours, trying everything under the sun, and realizing that not even a simple "Hello World" script would work from the browser, I finally found the problem.

I am still waiting for customer support to tell me something, because they first replied that they could not debug custom scripts but that they could set up a test script to demonstrate that CGI was working in Perl, to which I replied this morning to please show me a test script that would handle post request, which I thought was my problem yesterday and this morning, since the script worked from the command line without a post.

I don't know how it did that, because, after trying every thing I could think of, I decided to type "which perl" at the command line and to my utter surprise, it answered:
/usr/local/bin/perl

My server is horchata and up to now, perl had been at /usr/bin/perl

Did DH change it without advising, or did they just updated and placed it here now? I don't know. The current version that shows when typing perl -v is 5.8.4, but I don't remember what it was before.

The error log did not say it couldn't find Perl. It said it couldn't find a log and that fopen showed permission denied, which were cryptic messages to me.

Now scripts work and parse post requests from the browser, as they are supposed to. But I ask myself if this is something temporary and Perl will go back to /usr/bin/perl or if this is a permanent change.

At any rate, now I must rush to check my other websites, because it seems probable that scripts that were working before are not working now.

Sometimes, this business is frustrating.

Eagle

Eagle
Florida, USA
"If you think you can or if you think you can't, you 
are right"

In reply to:

---

I decided to type "which perl" at the command line and to my utter surprise, it answered:
/usr/local/bin/perl

My server is horchata and up to now, perl had been at /usr/bin/perl

---

That is strange - it should work either way.

On the genki server:

In reply to:

---

~$ which perl
/usr/local/bin/perl

---

In reply to:

---

~$ /usr/bin/perl -v

This is perl, v5.8.4 built for i386-linux-thread-multi

Copyright 1987-2004, Larry Wall

Perl may be copied only under the terms of either the Artistic License or the
GNU General Public License, which may be found in the Perl 5 source kit.

Complete documentation for Perl, including FAQ lists, should be found on
this system using `man perl' or `perldoc perl'. If you have access to the
Internet, point your browser at http://www.perl.com/, the Perl Home Page.

---

In reply to:

---

~$ /usr/local/bin/perl -v

This is perl, v5.8.4 built for i386-linux-thread-multi

Copyright 1987-2004, Larry Wall

Perl may be copied only under the terms of either the Artistic License or the
GNU General Public License, which may be found in the Perl 5 source kit.

Complete documentation for Perl, including FAQ lists, should be found on
this system using `man perl' or `perldoc perl'. If you have access to the
Internet, point your browser at http://www.perl.com/, the Perl Home Page.

---

In reply to:

---

~$ /usr/bin/perl5.8.4 -v

This is perl, v5.8.4 built for i386-linux-thread-multi

Copyright 1987-2004, Larry Wall

Perl may be copied only under the terms of either the Artistic License or the
GNU General Public License, which may be found in the Perl 5 source kit.

Complete documentation for Perl, including FAQ lists, should be found on
this system using `man perl' or `perldoc perl'. If you have access to the
Internet, point your browser at http://www.perl.com/, the Perl Home Page.

---

--rlparker

Hello Parker:

Thank you again for your new post.

FYI, when I type /usr/bin/perl -v in horchata, I also get the version 5.8.4, but the script did not work until I changed the shabang to /usr/local/bin/perl.

As a matter of fact, after I finished posting my last message to this forum and returned to MS Outlook, I had a reply from DH customer service which said:

"Hello,

Actually, that's not something we can do for you, however, I think I see the issue here:

horchata: 08:21 PM# ./display.cgi
: bad interpreter: No such file or directory

I fixed that, by entering the correct path to perl,

/usr/local/bin/perl

and it works:

horchata: 08:23 PM# ./display.cgi
Content-type: text/html
..."

First thing monday, I'll begin to check other scripts. Thanks again for your help.

Eagle

Eagle
Florida, USA
"If you think you can or if you think you can't, you 
are right"

In reply to:

---

horchata: 08:21 PM# ./display.cgi
: bad interpreter: No such file or directory

---

almost always when this happens what the problem is is that there are erroneous characters at the end of the shebang. Usually this happens when the files are edited on a windows machine and then uploaded with ftp.

if you do this:
cat -veT file.pl | head

and you see something like this:
#!/usr/bin/perl^M$
^M$
use strict;^M$

etc

then you need to run 'dos2unix' on the file.

The problem is that windows, mac, and unix have different formats for EOL (end of line).

Hope that helps!

Thank you Kitchen, for your help. I didn't know how to do that with cat piping into head. Good to learn something. The way I always checked a file type was by typing:
file filename.pl

It is also good to know that that error message usually means that the problem is about EOL.

Thanks again for your help.

Eagle

Eagle
Florida, USA
"If you think you can or if you think you can't, you 
are right"