February 28, 2021
Hot Topics:

Cross-platform Perl/CGI tips and tricks

  • By Dave Edis
  • Send Email »
  • More Articles »

December 4, 1998
Cross-platform Perl/CGI tips and tricks

by Dave Edis

Let's talk about writing cross-platform Perl/CGI programs. Cross-platform means that a program will work just as well on a Windows server as it will on a Unix server and vice versa. It also means that if a program is moved from one type of server to another, it can run without any modifications.

Not only does this make your code more portable and easier to set up, it also saves you time when you are developing a program on one server and installing it on another, or when your client decides to switch servers or Web hosting providers.

Figuring out what the cgi directory is

One of the biggest hassles in setting up a new program is figuring out the paths to data files, templates, and other required files. These can vary widely from server to server, and if you only have FTP access to the server on which you're installing your program, it can be very difficult to determine the full filepath.

Even when you know the filepath, you will need to modify it each time your program is installed on a different server. If you are constantly jumping from a development server to a staging server to a live server, this can be a lot of work.

The trick? In Perl the

variable contains the full filepath of the script currently being executed. By using a simple regular expression, we can chop the script name off the end and get the name of the current directory the script is in (
). Then we can access all our required files using relative filepaths. (i.e.,

### Find current directory path
if    ($0=~m#^(.*)\\#){ $cgidir = "$1"; }  # win/dos
elsif ($0=~m#^(.*)/# ){ $cgidir = "$1"; }  # Unix
else  {`pwd` =~ /(.*)/; $cgidir = "$1"; }  # Unix

The first line finds the cgi directory on a Windows server, which uses back slashes to separate the filepath. The second line finds the cgi directory on a Unix server, which uses forward slashes. Finally, we've found that on a very few Unix servers

isn't defined with the full filepath. In that case, we can get the current directory by using the Unix "pwd" command.

By using

, you'll never have to worry about server filepaths again.

How to "die" with something better than "Server Error 500"

Anyone who develops Web applications is all too familiar with that "Server Error 500" screen, the one that appears every time you have even the slightest error in your code. When something goes wrong in your program and Perl "dies," it exits the program currently running and makes an entry in the error log telling you what the problem was.

In many cases, it can be difficult to locate and view the error log to find out just what went wrong, and on some servers it's not possible at all (due to file permissions). As it turns out, there's a quick and easy way to replace that error screen with a helpful error message of your own design. By setting the signal handler for die, we can "catch" that die signal and tell the program to do something else before it dies. The following code should go near the top of our program so it runs before anything else.

$SIG{__DIE__} = \&Error_Msg;

sub Error_Msg {
  $msg = "@_";
  print "Content-type: text/html\n\n";
  print "The following error occurred : $msg\n";

You can customize your error message even more by specifying the "die" message and using

to tell you what went wrong. You can even have it print up a fancy HTML screen so it doesn't look so scary to the user. Also, by default, die will tell you the name of the program in which the error occurred and on which line, but you can prevent that (if you want) by putting a nextline character ("\n") at the end of your "die" message.

open(FILE,"<$cgidir/myfile.dat") ||
[break inserted here by editor to fit page; omit when copying!]

 die("Read Myfile : Can't open file $cgidir/myfile.dat : $!"); 

Now when your programs crash, die will tell you exactly what happened and why.

How to handle end-of-line characters and binary files

Windows and Unix handle end-of-line characters differently. Unix, for example, puts a single nextline character ("\n") at the end of each line in a text file to signify that that line is over and a new one has started. Windows does the same thing but uses two characters, a return and a nextline character ("\r\n").

This means that anywhere those characters are being read in, your program should recognize them as either "\r\n" or "\n". This could be while reading in data files, parsing text, reading form input, or so forth. If you're counting on one and you get the other, your program may not function the way you want it to. An easy way to account for this is to simply replace "\r\n" with "\n" like this:

$string =~ s/\r\n/\n/gs; 

Page 1 of 2

This article was originally published on December 4, 1998

Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Thanks for your registration, follow us on our social networks to keep up-to-date