Perl - a couple of lessons

Moving a Perl site to new hosting and trouble shooting when it refuses to work.

Perl eh, who remembers that? Who even knows what it is?

Outside of a few devotees, I’m not sure many people are aware of its existence or its purpose. Nor of what a great little (scripting) language it is for all sorts text processing applications.

“All sorts of text processing applications.” What a way to lose an audience! Two paragraphs in and most have already left. If you’re still reading then I thank you. It may not get better from here on in but at least you’ll know what to expect. Or not.

Where to begin?

At the beginning - obviously.

Perl is?

Perl is short for Practical Extraction and Report Language. It was originally designed to [practically] process a whole load of files and extract some useful information, formatting that information into a report.

Perl: My then

Way back when, one of my first clients used Actinic to run his web store. That worked by maintaining a local database. When changes were uploaded it generated Perl scripts and various data files and sent those up to the server. Very clever, but it did tie the maintenance of the website to a single computer. If I recall correctly the Perl it produced was heavily obfuscated.

Seeing Perl used in this way clued me into it being a possible means of producing my own web based software (shops, auction sites, etc.). The fact that it was available for Windows at no cost was another big draw. It is safe to say that Perl was my first introduction to Free Software and the whole Open Source movement.

Perl: My now

One of my original Perl shops is still running. Despite sporadic attempts to get the owner to switch to an all-singing, all-dancing more modern solution, its owner is adamant that its simplicity suits them and their customers.

To reap the benefits of https or SSL encryption on the website, I persuaded the customer to move onto my new Cloud based solution where we could take advantage of Let’s Encrypt’s free SSL certificates which bring zero cost https to the masses.

Perl: My nightmare

Because the shop script I wrote is compact - the main part comes in at just 26K including the HTML templates - moving the site proved remarkably quick. But the script just refused to run. Any pages returned a 500 Server Error with no further clue.

The cloud host is very good. It has a modern, fully featured cPanel, the ability to install all sorts of extras and a very responsive customer service team. Having established that there were no particular requirements on their part for Perl scripts, I was ready to begin the process of debugging.

Perl: My salvation

I began by installing the CGI::Debug module. Simply by putting this line:

use CGI::Debug( report => 'everything', on => 'anything' );

into the beginning of the file, those opaque 500 Server Error pages disappear and beautiful, information laden streams of text appear.

Perl: My solution

It was a simple problem. Somewhere along the line the (more up to date) CGI Perl module installed on the new host decided that it wanted its syntax to be changed ever so slightly, thus:

print $q->startform();
# SOME
# CODE...
print $q->endform();

needed to be:

print $q->start_form();
# SOME
# CODE...
print $q->end_form();

As easy as that! A quick Search and Replace led to the insertion of underscores in the appropriate places and all was well.

Having debugged the script and got everything working you now need to either remember to delete or comment out the use CGI::Debug module. I went with commenting it out to leave it handy for future use should I should ever need it.

## use CGI::Debug( report => 'everything', on => 'anything' );

Perplexed by Perl? Mixed up with your modules? Confused by CPAN?

Contact Us for friendly and competent Perl help!