Creating CGIs with Perl

Use of a CGI library

There are a variety of  libraries used in Perl scripts, most of them stored in Perl/lib. We call a library in a perl script by requiring (require lib1.pl)  or using (use lib2.pl).  A very common  library used in Perl scripts is  cgi-lib.pl ,  compatible with Perl 4 and above.

We have seen some functions of  the cgi-lib.pl  previously.  Lets take a closer look at version 2.18.

• PrintHeader - generates the required header for the reply of a server. See its use in hello.pl and the code here.
• ReadParse - will decode form information and place results in %in and @in . See example of code in form-decode.pl (the form is here).
• MethGet - returns true if the CGI call  uses the GET method. Most CGIs use POST, but it is advisable to test  for Method and return a form if the method is GET.  See bugreport.pl
• MyFullUrl - returns the full URL of the script. Used to make easy for users to run the script again.
• HtmlTop  - returns the initial HTML  tags of a page. You can specify the TITLE: &HtmlTop(Example 1) , but you cannot specify body background.
• HtmlBot  - returns the closing HTML tags of a page.
• CgiDie - returns an error message and quits. For example: &CgiDie(Unexpected error, terminating, sorry!)

Development of a Perl script

Scripts are created as seen in Essential Perl . Some minor modifications are needed however, for some characters used in Perl  that also have a HTML meaning, and vice-versa. Typically the use of   " (quotes), \  (backlash and . (dot)  in CGIs are a source of problems for beginners. these characters need to be "escaped" by the use of a \ (backslash) to avoid this problem. They  also create problems in regular Perl scripts  For example:
• <img src="$message_img"> needs to be coded as: <img src=\"$message_img\">
• print "<form method="POST" action="$cgi_url">\n"; also needs to be changed to: print "<form method=\"POST \" action=\"$cgi_url\">\n";
• print" print" $_\n\"; \n";  becomes print "print\" $_\\n\"; \n";

Using Perl to print HTML pages

A large part of most scripts is only a series of print statements, or similar, writing HTML pages to be send to the CGI requester as a reply.  A simple solution for creating the HTML part of the scripts is to create the HTML page(s)  using an editor and converting it (them) to Perl code. There are different ways to do it. Here are two of them:
• Use a Perl script to read the HTML file insert the proper Perl code like print-html.pl does, and then add the converted page into the Perl script. This works with all browsers, but requires inpection of the code generated and inclusion of the escape character (\) as discussed previously.
• Use  print <<HTMLPAGE;   insert the HTML page content (as many lines as needed) and just after it enter HTMLPAGE , where HTMLPAGE can be a name of your choice. It should work with most modern browsers. Test for characters that require escape (\) is not needed in this case.

Porting Perl CGIs from Unix to Windows 9x/XP/2000

Difference in File Systems

The detailed discussion of UNIX and Windows file systems are beyond the scope of this tutorial. If you "need" to know more see a summary and a detailed reference for UNIX .

UNIX does not use a drive letter like Windows, and directories and file full names are separated by / (slash) not \ (backslash) as Windows do. So a file name in UNIX would be /usr/project/home.html while in Windows we would have something like c:\usr\project\home.html.  If you have wondered why URLs are writen like http://home.ubalt.edu/abento/home.html now you know why -- the Internet was developed using UNIX terminology and conventions.

File names in UNIX do not have required extensions like in Windows.  job is a valid name in UNIX and both Windows 95/XP/2000 can also support file names without extensions, but not DOS. Long file names are also supported. But, in UNIX the . (dot) is a character as any other in the file name -- e.g. sales.report.1  The consequence is that dir * in UNIX is equivalent to dir *.* in Windows.
 

System commands that only exist in UNIX

A more serious issue is one related to commands that only exist in UNIX with no equivalent in Windows. Classical problems in CGIs  are: sendmail, crypt and  grep.

Sendmail is a very sophisticated mail system that is a command in UNIX, not a separated program (refer to the class in forms and CGIs for our discussion of  mail-lib.pl instead in Windows).

Crypt allows the encription of files and particularly passwords and it is also a native command in UNIX.  Perl 5  for Win32 build 110 and above includes it --  example: $passwd = crypt(test99, substr($passwd, 0, 2));  -- where test99 is the non-encrypted password value.  You can save the password to a file and later compare with input. See a very simple example in exist-crypt.pl

Grep is a very advanced search tool  frequently used for HTML page counters, search engines, etc. There is no generic substitute, you can either use an UNIX port of grep for Windows, or write specific scripts or programs to perform a given function.
 
There are, without doubt, other commands that are source of problems, like cron, date (different format), etc,  but the three above commands account for the majority of the port problems.

Perl features not converted to Windows 95/XP/2000

ActiveState has been pretty active in porting most features of Perl from UNIX to Win32. Most Perl 5 commands and libraries are now working in Win32. There are still some exceptions as listed in the release notes.

If you try to port a Perl command or library, and it does not seem to work, I suggest that you read the release notes of the build you are using.  Also please note that cgi-lib.pl is no longer part of the standard distribution of Perl for Win32.  Remember to download a new version of cgi-lib.pl  and add to Perl/lib in order to provide compatibility with many scripts available on the Web.