Perl script Installation Tips

These scripts have been developed exclusively for the Bestnetcraft. They are available for free to be used in your servers, unless otherwise indicated. They are offered as-is and in good faith. It is unlikely that the scripts listed in our server will do any lasting damage to your server. We will not be responsible for any malfunction or damages. Please read all the instructions accompanying the scripts before you invoke them. If you find these scripts useful, a word of appreciation will kindle the spirit further for future addition/upgradation. Flames and spams will be consigned to "/dev/null".

Perl (Practical Extraction and Reporting Language - invented by Mr.Larry Wall )is a powerful language and arguably powers most of the Internet. It assists the much maligned System Administrator in most of his routine chores. It has a low learning curve. Has extensive ability to parse and manipulate text from a large file using regular expressions. You don't have to write tens of lines of code to accomplish a simple task. One line of pithy perl code can do wonders too. Development in Perl has a comparatively shorter time frame. More than anything else you can draw on the hardwork and inspirations of thousands of other dedicated Perl programmers (Perl mongers). Just check out our resource page for links to the vast repositories of the Net and you will find that most of the Scripts available are in Perl. Perl is available in two flavors for Windows:
Active Perl for Windows (version 5.6.1.630 as of now) comes with a host of many modules,sample scripts and applications. Suitable other modules of interest - Perl for ISAPI - IIS plug-in that enhances the speed of standard Perl.
PerlScript - ActiveX scripting engine, like JavaScript or VBScript with a Perl brain.
PerlEx - Embedded Perl.
You can download the complete binaries and other files in a zipped format here
Bear in mind that Active Perl binaries differ slightly in implementation from the "regular" Perl. If you seek to host your CGI/Perl scripts eventually in Linux/Unix environment, you might like to stay with the "standard" Perl 5.6.1 - avilable here
All the binaries intended for Windows OS, come with installation routines which will set the path as per the installed directory. To test your Perl, just type at the command line (DOS prompt):
perl -v
which should invoke the Perl interpreter to display the version and the distributer/copyright information. Perl comes in handy for lots of system administration jobs too - even in Windows. You can look for patterns in a large log file. For example the following lines will count the number of lines in a text file:

#!/usr/bin/perl
# The above shebang line is not neccessary for command line execution
@data=; # enter the file name when asked
$c=0;
foreach (@data){
$c++;
}
print $c;

Before you launch the scripts from your server, it is imperative that you are familiar with the basic concepts of CGI scripts. This "README" is applicable for all the Perl scripts in general. At the least, you will get the dreaded "Internal Server Error - 500" message from your server. That's a way of complaining that, you may have missed out some rudimentary things in the scripts before they are uploaded.The drill is as follows:

This is the first line of all the CGI scripts to indicate to the server - the location of Perl interpreter. Most of the Linux/Unix machines have their Perl in this location. If you are not sure, check with your Sysadmin. If you have telnet access type "whereis perl" at the prompt. You can also type "which perl" at the console. If you are working with Windows, the shebang might be "#!C:\perl\bin\perl.exe". Find out where the Perl binary (executable) is and change the shebang accordingly.

If your CGI script uses some modules or if it uses some environmental variable which is missing, it can throw an error. If you have telnet access to your server, type at the prompt "perl -V" which should give a couple of screens of information relating to your environment and the Perl binary. Watch out for the "-v" invocation which returns only the version information.

If you have a wrongly set shebang, the Server will return a "Internal Server Error - 500". Check your error_log for details. Most servers including Apache are NOT noted for their user-friendly error messages. Use some routines to give an idea why something is not working the way they should. In most of the scripts in our collection we have this "nyet" routine to print out an error message in human readable format at the browser. We have no specific reason to use the Russian word "Nyet" -no- for this purpose. We have no antipathy against any religion,region,language,creed or color - although we may be biased in favor of blue,red or violet color.

Remember to upload your CGI files the right way. When transacting between a *nix machine and a Windows machine, the file mode is important. All image files,swf,sound files,executables and zipped files go as "binary" mode whilst all text files,HTML,js,pl and CGI files transfer as ASCII.

Check the permissions you have set for the scripts and for the directory. You need to set them to execute like this:
chmod 755 script_name
This will, of course, work only for Unix/Linux boxes. Depending upon the way the server is configured, you need not append any extensions to the script like -".CGI" or ".pl" to invoke the scripts. In windows, the CGI scripts need to have the extension - "pl" to work properly. Again most systems insist that these scripts are located in a folder/directory called "CGI-BIN" which carries appropriate permission. If your script wants to write to a file, this file requires to be located in a directory with the requisite permission for the HTTP server to write. Check with your Sysadmin all these details. It may seem insignificant at this stage, but eventually, you may need to spend hours trying to get the script going.

If everything else fails to activate your scripts, then it's time to seek professional help. Use the contact page to indicate the nature of the problem and the resultant error messages. Messages like "&*^*%$X Script doesn't work" don't help much.