Installing Perl Scripts

NOTE: If you prefer, you can hire me to install the script for you. Depending on how complex the installation, it will cost you somewhere between $35 and $75. Shoot me an email and I'll give you a price.

When installing a Perl/CGI script, there are a few main things to keep in mind:

  1. Setting the right path to Perl at the top of the script.
  2. Ensuring that any special characters are 'escaped' in the user-variables section.
  3. Uploading the script in ASCII format, not binary.
  4. Putting the script in the right folder (ie: cgi-bin most of the time, and sometimes other places)
  5. Setting the proper permissions on the script so that it will execute.


If the above requirements are satisfied, your script should run-- even if it isn't perfect. If it's programmed well, it should then be able to report to you what's wrong, or what you need to do to make it behave correctly.

Let's go over each of these items line-by-line, and flesh out some more detail.

1. Setting the right path to Perl at the top of the script.


Unlike typical Windows executables, Perl scripts are compiled 'on the fly.' This makes them ideal for cross-platform situations, because each machine that runs the script can decide how to best carry out the various commands.

The first line of the script is therefore extremely important, especially in non-Windows settings. It tells the server where the compiler is located on the machine, so that it knows how to handle the script.

Typically the location of Perl is one of the following:
#!/usr/bin/perl
#!/usr/local/bin/perl

If you're not sure what the proper path to Perl is for your server, check the FAQ pages on your web host's site.

top

2. Ensuring that any special characters are 'escaped' in the user-variables section.

Many Perl scripts contain a section at the top which allow you to add your own customization. Some examples would be the location of 'SENDMAIL,' your admin's email address, etc.

Making a mistake in this section often will not disable a script from working, unless you have not escaped special characters.

Some examples of special characters would be the at sign (@), an apostrophe (') or quote (").

Here's a situation: you have a variable like follows:
$email = "jasonsilver@mydomain.com";

You must escape the @ sign, or the script will think that mydomain is a special kind of variable called an array, which is preceeded by this symbol. One escapes a character with a backslash:
$email = "jasonsilver\@mydomain.com";

Another example:
$name_of_site = 'Jason's Site';

Notice the three apostrophes? This causes an obvious problem. We can do either of the following to repair it:
$name_of_site = "Jason's Site";
$name_of_site = 'Jason\'s Site';


By changing the type of quotes surrounding the variable, or by escaping the apostrophe, we solve our error problem.

top

3. Uploading the script in ASCII format, not binary.

Many times I see individuals who are new to web design using programs like "Microsoft FrontPage" to design their sites. This type of program makes it much easier to design a web page, without learning HTML, the coding behind it.

It can present some problems if you use Microsoft FrontPage's web site explorer to upload files. As far as I'm aware, FrontPage always uploads files in binary format. But binary format is death to Perl scripts-- just as ASCII format would kill a JPEG or a GIF.

Therefore, you should try to locate a real FTP (File Transfer Protocol) program for uploading and downloading files. A good one will allow you to upload in ASCII or binary, and will also allow you to change the permissions on the files you upload.

You should also try to learn HTML-- it's not hard, and will make a huge difference to both your file sizes (they'll be smaller), and your ability to do special things not possible with FrontPage.

top

4. Putting the script in the right folder (ie: cgi-bin most of the time, and sometimes other places)

Most of the time your web host will have a special folder where you can place CGI scripts. Often this folder is located below the root of your HTML pages, which is supposed to make your webserver more secure.

If a Perl script ends in the extension ".pl" then usually this script needs to reside in the cgi-bin. Some hosts allow you to place scripts in any folder, simply by changing the extension to ".cgi" so you might want to try that if you're having trouble.

If you create a subfolder of your cgi-bin, then often you will need to CHMOD (set permissions) on this folder too, so that all files within it will execute. More on that below.

top

5. Setting the proper permissions on the script so that it will execute.

There are two main permissions that need to be set on files. Those are '755' which allows a file to be executed, and '777' which allows it to be written to. Obviously, there are many more options for file permissions, but these should be sufficient for your needs.

So a script, like a file which ends in .cgi, or .pl, would be CHMODed to 755. A text file which contains a flat database, for example, or some other type of changing data, would be CHMODed to 777. Setting permissions is not usually necessary (or possible) with Windows servers. But with UNIX type hosts, you'll need to find an FTP client that allows you to send a special command to the server called 'CHMOD.' I prefer to use WS_FTP LE, which you can likely find by Googling for it. (If not, let me know, and I'll hook you up.).
With WS_FTP, once you upload the file you can change the permissions on it by 'right-clicking,' and choosing CHMOD. A dialog box like the one pictured above will appear. You can check the right boxes to set permissions, then press OK.

In the Spotlight

FavSync Perl $0.00
Add to Cart
 Together with the FavSync program, you may View the contents of your Internet Explorer Favourites menu on your web server.
[more & download links]

What People Say

Browser Page Editor $0
Add to Cart I looked into every solution all summer and for basic CMS this is just perfect. I only found it by using the right search term, 'browser based CMS' I think. Previously everything that pulled up were the hair pulling sql/php hair pulling things. Those solutions are like using a bazooka to swat a fly. Joomla's powerful but a nightmare when clients already have highly specific designs they don't want changed.
Dan Butler

[more & download links]

Post Page Comment