|
Well, the coolness is natural, we make the scripts free
because we learned most of what we know from open source software so as we
learn, we give back what we created along the way. Also, we sure do
hope that you remember us when you are looking for someone to write
custom scripts or webhosting. Just email me support@fuzzymonkey.net for a quote
:-)
|
Well, this could be any error. The best way to see what
is going on is to look at your web server error log. On many
linux systems this is in the /var/log/httpd/ directory.
If you do not have access to your web server error log, you can find out
lots of information by running it from command line. You will want to
telnet or ssh into your server. Then `cd` to the directory containing
the .cgi script. To run it, do:
$ ./scriptname.cgi (where scriptname.cgi is the name of the
script)
Depending on the webserver, it may now ask you to enter name=value
pairs. At this point, just hit CNTL-D and it will output a combination
of HTML and/or errors. If you want to test the script with giving it
input parameters (e.g. the stuff from forms) then you would enter those
name=value pairs first, one per line, and then hit CNTL-D.
If it doesn't ask you to enter in the name=value pairs, and you want it to, you can
edit the use CGI; to say use CGI qw(-debug);.
If you do not have telnet or ssh access or if you encounter an error when trying to log in,
contact your web hosting company. Many times, they will be willing to enable ssh or telnet
temporarily on your account if you tell them that you need it for troubleshooting purposes.
If this info is not helpful, some common reasons for getting this
error are:
- not having permissions on the .cgi scripts set to 755 (chmod 755
filename.cgi)
- not having perl installed at /usr/bin/perl (see the next
question)
|
|
Check to make sure you have perl installed and that it is located in
/usr/bin/perl. You can do this by doing:
$ whereis perl
this should tell you where perl is installed. If it is not
installed, install it from www.perl.com.
If it is somewhere besides /usr/bin/perl then change the first line of
all of the .cgi files to reflect where it is installed.
If the script says "file not found" or "no such file or directory"
this could be because the file is a DOS text file or was uploaded in the
wrong mode. Remember to upload the files in ASCII mode, not binary mode.
|
|
The problem is that the script you are running needs to
read or write to files which it doesn't have access to. Normally,
these files are written in the same directory where the script is or
some other directory that you specified when you set the script up.
When your script executes, it gets under a certain user account. If
you are running an apache server, this is most likely the user
'apache' or 'nobody'. There are a few ways to fix this:
Do not be tempted to set the permissions of everything to 777! If the script isn't working at 755,
then permissions are not your problem. In fact, many webservers are set up to refuse to execute anything
with permissions set to 777, because this is such a security risk.
|
|
This error either means that you do not have one of the required perl
modules installed, or that perl can't find it. If it isn't installed, just install
the perl module :-)
If you have root access, just go to search.cpan.org, download it, and do this
on commandline:
$ perl Makefile.PL; make; make install
If you don't have root access (e.g. you have a hosting account you
pay for by month), then you have 2 options:
If the perl module is installed and you are still getting this error, it means that perl doesn't know where the module is on the server. @INC is an array (a way to store data) that contains all the known locations of perl modules installed on the server. You can either reinstall the missing module into one of these known locations, or modify the script to look for the module. In order to do this, you need to know the location of the missing module. This could be something like "/usr/lib/perl5/5.8.5/CGI.pm" or "/home/username/lib/CGI.pm." It will be a full path ending in a .pm file. The path you need to put in the script will be that entire path minus the name of the module. In this case, that is CGI.pm, so our path would be "/usr/lib/perl5/5.8.5/." In cases like Image::Magick or MP3::Info where the name of the perl module contains "::," the path will contain an extra folder like "/usr/lib/perl5/5.8.5/Image/Magick.pm" or "/usr/lib/perl5/5.8.5/MP3/Info.pm." In this case, you'll need to remove the "Image/Magick.pm," not just "Magick.pm." When you've got your path figured out, open all of the .cgi files that contain a "use" line for the missing module. The "use" line will look like this:
use Image::Magick;
There may be several "use" lines in a row. Immediately above all of the "use" lines, put the following code, including the path to the missing perl module:
use lib "/usr/lib/perl5/5.8.5/";
Now you've told perl where to look to find the perl module, and it should begin to work!
|
|
You probably forgot to put the use lib lines at the top of the
scripts! If you don't have root access, you can't install the modules where perl expects them to be. For
this reason, we must tell perl where we intend to keep the perl modules. (see number 6)
|
|
This is usually either a permissions problem or a path problem, and our scripts will
normally tell you which it is. If it says something like "Oops! Can't open file for reading (or writing): Permission denied!"
it is a permissions problem. You can check the permissions by logging in on commandline with ssh or telnet and typing "ls -l."
If it says something like "Oops! Can't open file for reading (or writing): No such file or directory!" it means that the
folder or file the script is trying to access does not exist. Sometimes you will need to create a folder, and sometimes you
will need to change your settings to reflect the correct path to the data file or directory.
|
Here is the long version of that error message:
Can't modify subroutine entry in scalar assignment at lib/sitevariables.pm line 25, near "'My Classifieds';"
syntax error at lib/sitevariables.pm line 50, near "our @cellcolors "
syntax error at lib/sitevariables.pm line 101, near "our @categories "
BEGIN failed--compilation aborted at lib/common.pm line 24.
BEGIN failed--compilation aborted at /home/sites/site104/web/mockad/index.cgi line 57.
If you are getting this error, it means you have perl version 5.003 or earlier, which doesn't support some of the
functions that our scripts use. There is an easy way to fix this error:
- In the .pl, .cgi, and .pm files, including those in the lib/ directory, on every line that begins with "our,"
you must delete the word "our" and nothing else.
- In the .pl and .cgi files, delete the entire line near the top that says "use strict;".
- In index.cgi and lib/functions.pm, delete the entire line with the word "mkdir" in it. This function is also not supported by your version of perl.
|
By all means! Please send me the patch (.diff) or email
and tell me about it. You can reach us at support@fuzzymonkey.net.
If you have suggestions or corrections for this page, please let us know! Good luck and send us links when you get our scripts running!
Erin
|
