This page will take a minute to fully load as
there are a number of "screen-shots" and diagrams.
A lot of people have Web pages but most feel that CGI scripts are
"over their head". Nonsense! If you know basic HTML and know how to use
an FTP program like WS_FTP to transfer files, chances are you can be using a
CGI script on your Web pages in about 15 minutes. With so many
free CGI scripts available you are really short-changing yourself if you are not
using the CGI capabilities offered by your ISP or host provider to use CGI
scripts.
While there are a lot of "CGI Tutorial" pages out there, most
deal with how to write CGI scripts. For those who just want to know how
to use CGI scripts, information is pretty scarce. That's why this page
was created.
What Is CGI ?
You've
undoubtedly visited Web pages and seen "cgi-bin" appear in the location line
of your browser. CGI stands for "Common Gateway Interface". It is a
server-based service which provides a means of adding expanded functionality
to Web pages over and above what HTML provides. This expanded functionality is
provided by using small programs, or "scripts", that are executed on the
server the Web page files reside on. When you see that "cgi-bin" appear on the
location line, you probably executed a CGI script on the server when you
initially loaded the page, or will in the course of using the page.
CGI is utilized by placing an appropriate HTML tag in your HTML
document ("Web page"). The author of the script you wish to use should provide
you with the appropriate HTML tag needed to run that script. When the page is
loaded by a browser, i.e. viewed by a site visitor, the tag "calls" the script
and it is executed by the server. Note that this is different from Java
applets or JavaScript, which are executed on the client (visitor's) system via
their browser.
CGI and Perl
You will
often see the term "Perl" used with the term "CGI". The two are NOT the same.
CGI programs, or scripts, can be written in a variety of computer languages,
including C. CGI is the process by which scripts are run. Perl is
the most common language used for writing CGI scripts, and for very
good reason.
Because Perl has its' roots in Unix, many
people think that Perl CGI scripts cannot be used on Windows NT Web servers.
Not true! Perl CGI scripts can not only run on Unix and NT
servers, but with a little tweaking for "AppleScript", many can run on
Macintosh servers as well.
Your CGI
Most ISPs that offer Web space and Website "hosting" companies support
the use of CGI scripts. It is so common in fact, that if your ISP or host
provider doesn't offer it, you should consider taking your business elsewhere.
The two questions that need to be answered are:
1. Can I run CGI scripts from my Web pages ?
2. Does
my CGI script support include SSI (Server Side Includes) ?
Note: Don't confuse SSI with SSL (Secure
Socket Layer), they're two entirely different things.
If the answer to both of these questions is "Yes",
you're good to go. You can run most of the scripts available on the Web. There
are some scripts that don't require SSI but a lot do so having SSI support
will allow you to run more scripts. However, if you don't have it you can
still run some scripts. The documentation (readme file) should come with the
script and state whether it requires SSI support or not.
"Server-Side Includes" are just that, commands (aka
"directives") to the Web server to include some information the server has
in the displayed Web page. A common use of SSI is to display the current
date and time on a Web page. These commands are enclosed within HTML
comment tags (<!-- -->) in a Web page so the browser
ignores them. These comment tags with an enclosed server command are the
"SSI directive tags" that are mentioned below. When these SSI directive tags
are used with scripts, the "...information the server has..." is whatever
output was generated by the execution of the script. The script will dictate
whether this information is displayed on the Web page (as with a hit
counter) or written to some file (as with a logger). As an example, here is
the HTML (SSI directive) tag for Bestdam Logger:
Back to your CGI situation. Most Web
hosting services and ISP's have a Technical Support section on their Website
that may also have a "FAQ" (Frequently Asked Questions) page. Snoop around
their support pages and see if they if you can find anything related to CGI
and SSI that may answer the above questions.
If all this talk of Perl,
SSI, Linux, etc. has you a little confused, here's a diagram to show the
inter-relationship of the various components of a typical Internet server.
Note that "Apache" and "Sendmail" are like brand names. There are other
Web-sever and e-mail-server software packages available.
One way to
tell if you have CGI capability is if you have a sub-directory (folder) in
your root Web directory called cgi-bin. If you do, you very likely do
have CGI capability. The only question then is, does your CGI capability
include SSI support ? If you didn't find an answer to this on their
Website, you will have to check with your host or ISP.
If you don't have a cgi-bin sub-directory that doesn't
necessarily mean you don't have CGI capability. It could mean it hasn't been
set up.
Normally you cannot simply create the
cgi-bin sub-directory yourself. It is a special sub-directory that must
be set up by a system administrator. However, I have seen hosts that allow you
to create the sub-directory using an FTP program and use their Website "admin"
function to enable it. If you are able to create it, how to CHMOD this
sub-directory is given at the end of the next section.
Note that your
host provider or ISP may set up a sub-directory called simply cgi
rather than cgi-bin. This is the same thing and you would just need to
make the necessary changes to any tags you add to your Web pages to run
scripts.
In some cases, hosts or ISPs that do not offer CGI capability
with their base package will offer it as an "add-on" or optional service for
an additional fee.
Three Steps To Using a
Script
Once you've established that you do have CGI and
SSI capability, there are three basic steps you need to take in order to use a
script on your Website:
Set any options that the script may need
Transfer the script's files (the script file itself and any necessary
data files) to the server
Add the script's HTML tag to the page(s) you want to use the script
Perl scripts typically have a .PL extension, but they may
also have a .CGI extension. (Files with other extensions, or no
extensions, will likely be data files used by the script.) "Setting options"
in scripts is typically just a matter of opening the .PL (or .CGI) file in a
text editor and entering values for some of the scripts variables. For
example, you may need to enter your e-mail address if the script sends e-mail
notifications of some event. Details on setting script options for
Follow Up Autoresponder
are in the readme.txt file. However, the top of the config.cgi file is
heavily commented with instructions for setting the options so you may be able
to set them just by opening the file in a text editor and reading the
comments.
Note: Some hosts or ISPs may require that scripts
have a .cgi extension. It is normally not a problem to just rename
the file to comply.
With the script all set up and ready to go,
the next step is to transfer the script files to your Web server and set the
proper "permissions" to the files. These permissions are necessary so your
Website visitors can access them properly (covered in detail in the next
section).
That takes care of the script side of things. The final step
is to add the appropriate HTML tag to your Web page (HTML file) to call the
script and then transferring that updated page to the server. The
documentation that came with the script, or the comments in the script file
itself, should include the appropriate tag to use.
But remember that
you may have to modify this tag. Most tags assume your CGI sub-directory is
called cgi-bin. If it's called simply cgi, or something else,
make the necessary change in the tag.
Taking the above Internet server
diagram and adding another box and a few more lines, you can see how your HTML
file completes the process.
Transferring script files to your Web server is not much different
than transferring your Web page files there. The main differences are that
you'll be putting them in their own sub-directories and, if your server is
running a Unix or Linux operating system, setting the permissions to the
files.
The screen-shots in the steps below are using the WS_FTP program
but other ftp programs should have similar functions.
Go into the cgi-bin sub-directory (i.e. open the cgi-bin
folder by double-clicking on it)
Example:
Make a new sub-directory (folder) under cgi-bin with the name of
EZAR or TMAR
(ez-response auto responder) by clicking on the MkDir button.
Technically, you could just transfer the files into the
cgi-bin sub-directory but, because you may want to use additional
scripts in the future, it is best to put each script in its' own
sub-directory.
Double-click on the new autoresponder folder to open it and
USE ASCII MODE !!! to transfer all 5 of the following files into
the new autoresponder sub-directory (the readme.txt file that comes with
Follow Up Autoresponder does not have to be transferred):
activate.cgi
config.cgi
swars.cgi
lite.pm
readme.txt
NOTE: If you are using any version of
Windows, the file names may have been changed so that the first letter of the
file names is upper-case. Make sure the file names are all lower-case letters
once they are on the server. If they are not, use the "Rename" button of your
FTP program to change the file names to all lower-case letters on the server.
Setting File Permissions
Web servers will generally be based on one of two operating systems.
Either some "flavor" of Unix or Linux, or Windows NT. Step 4 is necessary only if your pages are hosted on a
Unix/Linux server. Most are. Check with your ISP
if you're not sure of your server's OS.
Once the files have been transferred you have to set file "permissions" so
people can access them. The Unix term for setting file permissions is
CHMOD. You must CHMOD the
The
above numbers are based on the "binary" number system used in computers. If
you don't know what that means don't worry. You can CHMOD files using WS_FTP
as follows:
click once on the
activate.cgi
file name to highlight it
right-click on the activate.cgi
file name and select
"CHMOD" from the pop-up menu
set the
activate.cgi permissions to 755 by selecting the following
in the three columns:
Under Owner - select Read, Write, and Execute
Under Group - select Read and Execute
Under Other - select Read and Execute
click once on the
swars.cgi
file name to highlight it
right-click on the
swars.cgi
file name and select
"CHMOD" from the pop-up menu
set the permissions to the
swars.cgi
file to 755 by selecting the
following in the three columns:
Under Owner - select Read and Write
and Execute
Under Group - select Read and Write
Under Other - select Read and Write
repeat the previous two bulleted items for the remaining files
click on the Refresh button to the right of the server file
display
click on the DirInfo button to the right of the server file
display and you should have the following:
rwxr-xr-x
activate.cgi
rw
x-rx-rx-
swars.cgi
rw-rw-rw-
lite.pm
rw
x-rx-rx-
config.cgi
readme.txt
For future reference: Let's say that you've been
using a script and you find out there's a new version of the script file
available. You obtain a copy of the new script file, set any required
options, and you're ready to transfer it to the server. If you overwrite
an existing file by re-uploading it you don't have to set
the permissions again. The permissions are tied to the file name,
not the file itself. So if the new version of the script file has the same
name as your existing version, it's better to just re-upload it
without deleting the old version first.
IMPORTANT: If you created the cgi-bin sub-directory
yourself because this is allowed by your host or ISP, use the above
procedure to set the permis
sions to the sub-directory to 711 by
selecting the following in the three columns:
Under Owner - select Read, Write, and Execute
Under Group - select Execute
Under Other - select Execute
so that the Dir Info for the
sub-directory is "drwx--x--x".
Now that you've got the script files ready to go, it's time to take care
of the script's HTML tag. This tag may be an "SSI directive". Which pages need
the tag depends on the script. Typically, most scripts only require the tag to
be placed on one page.
Important Note: Be careful about putting the script's tag
on multiple pages. A script will usually only have a single data file for a
given function. For example, if you install a very simple hit counter script
and you put the tag on multiple pages, the "hit count" displayed could be
the cumulative hits of all the pages having the HTML tag. You
have to look at the documentation that came with the script. Some hit
counters do have "multi-page support" for simultaneously tracking hit counts
of multiple pages in one data file.
Open your Web pages in
your HTML editor and add the script's tag keeping the following in mind:
Make sure you put it before the closing "body" tag
(</body>).
If the script is a hit counter or something else that displays something
on your page, the placement of the tag in your HTML document will determine
the placement of whatever's being displayed (hit count, etc.) on your Web
page.
Unfortunately, given the large number of possible server configurations,
your host or ISP may have the following requirements. Check with them if you
run into problems trying to run the script.
If you're using a script that requires SSI, the Web page with the SSI
directive tag must have an .shtml or .shtm extension. Check
with them regarding any such requirement. (This could present a problem if
your page is already indexed or referenced on a lot of search engines or
directories with a different extension.)
You may need to use a relative path in your tag. For example,
Once the tag is added to the
appropriate page(s) and the changes have been saved, transfer them to your
server as you normally would. i.e. Do not transfer them into the
cgi-bin sub-directory or any sub-directory under it.
If You Plan To Use Graphics Counter Digits
make a new sub-directory (folder) under your root Web
directory and name it digits
Double-click on the new digits folder to open it and USE
BINARY MODE !!! to transfer the digit graphics files of your choice
into your new digits sub-directory
You do not need to CHMOD these files as they only need to have the
Read permission and that is assigned by default.
IMPORTANT NOTES:
The graphics files must have
the single character name for the number they represent. For example, if they
are .gif files, they must be named:
1.gif 2.gif 3.gif etc. Use the
"Rename" function of your FTP program to rename them if necessary.
Do
NOT create the digits sub-directory under the cgi-bin
sub-directory or people may not be able to access the digit files.
Here is an example of a count displayed when using digit graphics
files:
As mentioned previously, most CGI scripts are written using the
Perl language. When a Perl programmer writes a script they may choose to make
it freely available to everyone on the Web. However, you should use caution
when selecting these free scripts. I have seen many instances where these free
scripts do not adequately "lock" files (which is important in a Web
environment where multiple people could be viewing the same Web page
simultaneously). Some poorly written scripts could also actually pose a
security risk by allowing unauthorized access to the server. Unfortunately,
there is no easy way for the untrained eye to determine if adequate file
locking is used or if the script represents a security hole. And most Websites
that offer scripts from third parties for download do not perform any sort of
quality control checks. When in doubt, ask your host or ISP to look over the
script you want to use. Most would much rather take a couple minutes to
evaluate a script than clean up the mess a poorly-written script could cause.
The Files
Perl scripts typically have a
.PL extension, but I have also seen them with a .CGI extension.
Files with other extensions, or no extensions, will likely be data files used
by the script. Serious Perl script programmers will also include a
readme file that contains information about the script and how to set
it up. This readme file is intended for those who will be using the script and
does not have to be transferred to the server with the script and data files.
More complex scripts may have more than one .PL file which may
require different HTML tags for each one. (It's also possible that one script
may "call" another script so that only one tag is needed.) Also, be on the
lookout for additional .PL files with names like config.pl or
cfg.pl. These are script files where all of the user-settable options
are entered and stored. If a file like this is included in the download file,
you typically don't have to open the main script file to set options. The main
script will refer to this configuration script each time it is executed.
All of these files are typically combined into a single .ZIP file for
you to download from a Website.
The Setup
Perl scripts are simply plain old run-of-the-mill ASCII text files.
However, instead of containing sentences that make sense to humans, they
mostly contain commands that make sense to servers. There is an advantage to
this though. Because Perl scripts are ASCII text files, the Perl programmer
can also put human-understandable instructions in the script, and many often
do, locating this text right at the beginning (top) of the file. It is easy to
spot the information that is meant for you to read because the line will start
with # character.
The # character is
the "comment" character in Perl. Any line that begins with a #
does not get executed by the server. In addition, the programmer can also put
a # character after a script statement to add comments.
For example, you could see the following statement in a script which acts as a
user-settable option:
$counthits = 1; # 1 = Yes
0 = No
Once you have downloaded and un-Zipped
a script that you would like to try, you should use a text editor like NOTEPAD
to open the main, or if found the configuration, .PL file and check the top of
the file for any information or setup instructions. If there is a
readme file, open that in a text editor and look for setup instructions
also.
One key piece of information you should find either in the
comments in the script file, or in the readme file, is the HTML tag you need
to add to your Web pages to execute the script. Using the file transfer
example in the previous section, the tag for autoresponder would be:
If you don't find the HTML tag given anywhere you can
substitute the sub-directory and script names in the tag above. Note that the
provided HTML tag with some scripts may assume you are putting the script in
the cgi-bin sub-directory, not a separate sub-directory under it. If
this is the case, and you want to put the script in it's own sub-directory
just modify the tag. For example, say you downloaded a script called
"GigCount" and the tag specified in the script's comments or documentation
was:
<!-- #exec cgi="/cgi-bin/gigcount.pl" -->
If you wanted to put the script in it's own sub-directory
named "counter" you would simply modify the tag to
<!-- #exec cgi="/cgi-bin/counter/gigcount.pl" -->
CGI scripts that do not require SSI might have
a more common type of tag. For instance, a counter script may have the tag
<img src="/cgi-bin/counter/gigcount.cgi">
I would also like to reiterate several points about possible
host/ISP requirements mentioned in the previous section.
If you're using a script that requires SSI, the Web page(s) with the SSI
directive tag may be required to have a .shtml or .shtm
extension. Check with them regarding any such requirement. (This could
present a problem if your page is already indexed or referenced on a lot of
search engines or directories with a .html or .htm extension.)
You may need to use a relative path in your tag. For example,
Scripts may be required to have a .pl rather than a .cgi
extension. This should not be a concern. It is normally not a problem to
just rename the file (and make the corresponding modification to the tag) to
comply.
In addition to a tag, the information near the top
of the script file or readme file should also contain instructions for you on
what values to use to CHMOD the files, as well as setting any user-settable
options the script may offer.
The very first line of any Perl
script is a user-settable option and is always going to be the path to your
host's Perl installation, preceded by the characters "#!". This line
is commonly referred to as the "shebang". Typical shebangs can be:
#!/usr/bin/perl (often the Perl 4 location)
#!/usr/local/bin/perl (often the Perl 5 location)
Note that Perl 4 scripts will work with a path to a Perl 5
installation but the reverse may not be true. If you're having problems
getting a script to work with the first one, try the second. Note also that
this first line may not be necessary with Windows NT servers.
If
you haven't yet done so, now would be a good time to snoop around your host's
or ISP's Website Technical Support pages and FAQs looking for anything related
to "CGI". There you may find not only the path to their Perl installation (and
possibly the version of Perl they have installed), but to their e-mail
programs and other paths as well. If you can't verify this information, just
leave it at the default value, but verify it with your host or ISP if you run
into problems trying to use the script.
If you know how to use the telnet program to access the
shell of your Unix/Linux server, you can use the
whereis command to find out the paths to your Perl
and sendmail installations. At the shell prompt, simply type in
whereis perl and whereis sendmail
and the paths will be displayed. Note that you will often get
multiple paths displayed, some ending with things like
/perl5.003 and /sendmail.cf but you
are only interested in the paths that end with
/perl and /sendmail -
i.e. with noextensions. There may even been multiple path
listings to these, but that just means there are different versions
installed.
You may also be able to find the system path
(see the paragraph below) to your Web directory by using the
pwd command (print working directory).
Setting options usually involves entering
values for script variables. These values can be a '1', 'Y', 'y', 'YES', etc.
to enable an option and a '0', 'N', 'n', 'NO', etc. to disable it, or certain
user or system information may be needed. In some cases you may be asked to
enter path information or an e-mail address. For example, near the top of the config.cgi
file you are asked for your e-mail
address (so the site visitor data can be e-mailed to you) and the path to your
server's e-mail program. The comments in the script or configuration file
should clearly indicate what the option is and what the valid optional values
are.
Some scripts will ask you to enter the system path. This
is not the URL. The system path is the path from the root of the server
which is hosting your site and will look something like this:
You'll have to ask your host or ISP if you don't know what
your path is. The problem is that they may not be too quick to give this
information up for security reasons. If that's the case, there's not much you
can do. You can try asking them to take a look at the script you want to use
so they can see how the path is used.
If some of what you read at the
beginning of the .PL file doesn't make any sense to you, don't feel like
you're doing something wrong. Many Perl programmers will write these comments
for other Perl programmers, or worse, for others who are well-versed in Unix.
If you find that the instructions are not clearly written for those without
Perl programming or Unix experience, and there is no accompanying
readme file with easy-to-understand instructions, you may want to
forget about using that script and find something with clearly written,
understandable instructions.
Detailed setup instructions for Follow
Up Autoresponder are given in the readme.txt file contained in the .ZIP download
file With everything set up in the script file it's time to transfer
the files and, with Unix/Linux servers, set the permissions (detailed in the
previous section). The most common mistake people make when using ftp to
transfer script files to the server is not using ASCII mode to transfer the
files. Be sure to use ASCII mode when transferring the script files
! A script will not work if it is transferred in binary mode.
Troubleshooting
The vast majority of
script problems are due to configuration issues. When you consider that there
are so many different flavors of Unix out there, multiplied by the number of
possible configuration options, multiplied by the number of Web server
software packages out there, multiplied by the configurations options they
have, you can see why this is the case. That's not to say you should go
running to your host or ISP if your script doesn't work right off. The truth
is, trying to solve problems is one of the best learning experiences there is.
There are a lot of things you can check, and if you do go to your host or ISP
and say "I have checked....." they'll know you have some knowledge of what
you're doing and take you seriously.
If you've set up and installed
and script and you feel it may not be working, there are certain steps you can
take using your browser to try and track down the problem.
If, when you try and view the page containing the script's tag, a
"server error" Web page comes up telling you to contact the system
administrator, try using the alternative Perl path. I've seen cases where
switching from the Perl 4 path to the Perl 5 path clears this up.
If the script is called with an SSI directive tag, bring up the page
with the tag in your browser and view the page source (with Netscape click
on "View" on the menu bar and select "Page source") and look in HTML code
for the SSI directive tag.
If the SSI directive tag does show up in the page source
listing it is not being processed by the server.
If it does not show up the server is trying to execute
the script so it is likely bombing during execution due to the way it's
configured.
You
may also have another troubleshooting tool at your disposal. If your host or
ISP generates an individual error log for your domain, it will likely
contain error messages which will indicate what problems were encountered when
the server tried to execute the script. The error logs are typically just
ASCII text files so you can ftp them to your local hard-drive and open them
using a text editor.
If you've had even basic exposure to computer programming or
Javascript you'll find that Perl is a very easy language to learn because of
it's script nature. In addition, because Perl scripts are ASCII text files,
you can look at the code of the scripts you use to see how things are done.
This text-based script nature means that Perl is an "interpreted" language.
i.e. compilation of a Perl script is done on the server every time the
script is called. CGI scripts written in some other languages, such as C, have
to be compiled manually (once) before they can be called. Even so, even large
Perl scripts tend to compile/execute very quickly.
Don't let this
ease-of-learning fool you. Perl is used for some very sophisticated
applications. In addition, it can be used with the free MySQL engine
for applications requiring the use of databases. While no one can predict the
future, I would suspect that as Linux becomes more and more popular as an
operating system for Internet servers, Perl will become more and more popular.
As an indication of the potential growth of the Linux market, consider that
Red Hat, a major distributor of Linux, had it's stock price rise over 600% on
its' first day of trading and it continues to rise. If you invested the very
short amount of time necessary to familiarize yourself with Perl, you could
begin writing your own scripts (not to mention develop a highly marketable
skill).
"Messin' Around With Perl" means just that. You don't have to
start out writing your own scripts from scratch. Read the License Agreement or
"conditions of use" that normally come with a script. Some script authors will
say it is OK to modify their script. Because they're just text files you can
take such a script, try using it for awhile so you know what it does, and
customize it a little bit. Transfer your customized script to the server and
see how your modifications affect the script's performance. (Keep a backup
copy of the original script with your options set in case you hose things up.
If you do hose it up, just upload this backup copy to your server to replace
the hosed-up version). The more you learn about Perl the more customizing you
can do. That will help prepare you for writing your own scripts from scratch.
Caution: Make sure you have a copy of
Perl-Win32 on your local system (see the "Good Books" section below) so
you can test your modified scripts. You don't want to try executing a
script on a commercial server without doing some preliminary testing first. A
rouge script could crash a server and since most hosting companies host a lot
of domains on one server, bringing it down could make you very unpopular with
a lot of Webmasters.
Perl Basics
If you
know just a few simple Perl things you'll be able to look at most Perl scripts
and figure out what they do.
A line staring with a # denotes a comment
(which doesn't get executed).
A word starting with a $ indicates that this
is a "variable" (i.e. a temporary holding area for a value)
A word starting with a & is a call to a
sub-routine (where the '&' denotes the call and the word is the
name of the sub-routine located elsewhere in the script)
When you see a period (.) between two variables it is
merely "concatenating" the two variables (putting them together)
A word starting with a @ indicates that this
is a single-dimension array. (Single-dimension arrays are referred to as
"lists" in Perl)
A word starting with a % indicates a
two-dimensional array officially called an "associative array" but more
commonly referred to as a "hash" (you'll have to read up on that one)
When you see a file open statement with a
< sign, or no symbol at all, the file is
being opened for a read operation
When you see a file open statement with a
> sign the file is being opened for a
write operation
When you see a file open statement with two
>> signs the file is being opened for an
append operation
Check it out for yourself. Here
is the Perl script for a hit counter. In viewing
the hit counter script you may have noticed that the name of the data file is
first assigned to the $countdata variable, and then that variable is
used in the open statements. While that's a rather round-about way of
doing things in a simple script like this I wanted you to see it as it's quite
a common practice. File names are assigned to variables, typically near the
start of the script, so that only one change is needed if you have to change
the path or file name for some reason, rather than looking through the code
for all of the open statements. In a simple script you could simplify
things by just using the file name in the open statement like this:
open (COUNT, 'counter.dat');
One thing you
probably didn't notice is that there was no file locking done in this script.
Bad news. Any time a file is opened for a write operation it should be
"locked" so someone else can't try to write to it at the same time. The script
should have an additional lock statement after the open-for-write statement
(one of the things you want to look for in free scripts):
open (COUNT, "> $countdata"); flock(COUNT,
2); print COUNT "$hitcount";
Perl is very flexible
and "programmer friendly". You don't have to declare variables or follow
strict rules as to their "type". For instance, if a string variable contains a
numeric digit you can mathematically add it to another string variable
that also contains a numeric digit. Perl handles the type conversions
automatically.
Real World Perl
Perl
started out as a reporting language so it has many features for handling text
and strings. That includes text and strings that are components of an HTML
document. As a result, you can use Perl scripts to dynamically create Web
pages on the fly. This can be more valuable than it first sounds. Consider
this example:
People in your organization would like to view a report
containing some real-time data. If this report is in, or you can get it to,
a text file you could create a simple Perl script to write the appropriate
HTML to a file. This file would be a Web-page version of the report that
people could view from anywhere using their browser.
Any text placed
between the <PRE></PRE> (pre-formatted) HTML tags
retains their spacing so a lot of other HTML tags aren't necessary to
replicate the report appearance. In between the
<PRE></PRE> tags you use a different kind of SSI tag
from the exec covered in the previous section. The include SSI
tag will include the contents of a separate file in a Web page. If the file
is named rt-data.txt the tag would be:
<!--#include file="rt-data.txt"-->
As a
result, the main pieces of Perl code for this script, lets call it
genrtr.pl, would be:
#!/usr/local/bin/perl print "Content-type:
text/html\n\n"; $reporthtml='rtreport.shtml'; . . open
(WEBREPORT, ">$reporthtml") || die 'Couldn't open HTML file'; flock
(WEBREPORT, 2) || die 'Couldn't lock HTML file'; . . print
WEBREPORT '<PRE>'; print WEBREPORT q[<!--#include
file="rt-data.txt">]; print WEBREPORT
'</PRE>'; . . close WEBREPORT;
The
print "Content-type: text/html\n\n";
merely sets a Web page as the default output "device". In this case, the
default Web page would be the standard server error Web page your host or
ISP has which would also display the die error messages if your
script runs into a problem accessing the data file. Since the Web page is
the default for output, we have to specify the HTML file
(using the WEBREPORT file handle) in all of the print statements.
The q[...] used in the second print
statement is just an optional way of quoting a string when that string
itself contains quote marks. The output of these three print
statements would appear as follows in the HTML page source file:
<PRE><!--#include
file="rt-data.txt"></PRE>
and the URL for the
created page would be (taking the file name from the third statement in the
above sample code):
http://www.yourdomain.com/rtreport.shtml
(As noted in the previous section, the '.shtml'
extension may be required by some servers for pages containing an SSI
directive tag.)
However, keep in mind that the script has to be run
from another page in order to create the real-time report HTML file.
You could run it from some sort of menu page where viewing the report is a
menu option. The tag you would put in the HTML for this menu page would be:
<!--#exec cgi="genrtr.pl"-->
This
menu page could contain regular text links to a variety of reports. Each
report would have to have its' own
exec tag in the menu page HTML
its' own script
it's own associated text file (real-time data) to be specified in the
SSI include tag (coded in the script's print statement)
Tip: There's no reason
you have to use Perl at all in order to take advantage of the SSI
include directive. Simply put the tag in any Web page to "suck in"
some external data or text whenever the page is viewed. (Note that the
text file could also contain HTML so you could, in effect, create one page
from several different files.) In terms of this example, if you only had
one report you could bypass the Perl script and menu page idea and just
create an HTML report page with an SSI include directive and give
the URL of the page to those who need to view it. (Each Web-server
software package tends to have it's own set of SSI directives. The
directives used here are for the widely used Apache Web-server software
that runs on most Linux servers.)
Taking the above
tip and bringing Perl back into the picture, you could use a script to test
for things like time of day, day of week, IP address, or any other host of
variables and branch to different print statements containing
different SSI include directives and vary the content of the
resulting Web page accordingly. You could also use additional print
statements in your Perl script to add HTML code for headers, footers,
company logo, links, etc. to a Web report.
You could also try
renaming a script file so it has a '.cgi' extension and
linking it to a graphics button. Using the above report script, the HTML tag
would be something like:
familiar
with
forms, you can also call a .cgi script file from within a form with
a tag like:
<form method="post" action="/cgi-bin/genrtr.cgi">
However, these above two methods will only work if the
script doesn't require SSI support. Scripts that require SSI support
need to be called with an SSI directive tag.
This example contains
Perl, HTML, and SSI material so it may be a bit overwhelming if you've never
worked with this stuff before but I wanted to use examples that could be
useful to you at some point in the future should you decide to pursue Perl
programming.
As you can see, Perl has many neat features
too abundant to cover here. Suffice it to say that you can be writing Perl
scripts within hours, not days, of reading up on it, and as your skills grow
you'll be amazed at what you can do with it.
Good
Books
Of all the books I've bought on Perl (about 12 of
them) the following four are the most valuable and useful. They are
excellent as either tutorials or in their completeness in their
coverage of the subject. Clicking on a book's cover will take you to
Amazon's "detail" page where you can read an overview of the book and
comments posted by those who have purchased it.
Note: If you think you may buy any of these books, either
now or in the future, please do so by using the book-cover links below
instead of going to Amazon.com directly. By using the links here I'll get a
small percentage of the sale which will help pay for the bandwidth the
graphics on this page need. Many thanks !
The
comments next to the book covers are my own and they are my honest opinions,
not a sales pitch.
The best book out there
for beginners, including those who don't know a lot about programming.
It comes with a CD that includes sample code and a copy of
Perl-Win32 that you can use on your Windows-based system to test
your scripts. The book covers using the Perl-Win32 software also.
It doesn't get into the real fancy Perl functions but that's not its'
goal. It's an "easy read" that will have you coding in no time.
Amazon customer review rating:
If you're an
experienced programmer this may be a good starting point for you. Very
comprehensive in it's coverage of Perl, addressing functions that the
"Dummies" book doesn't get to. The information is presented in a very
easy-to-understand manner and doesn't assume you have a Unix background.
(A lot of the more advanced books do.) Amazon customer review
rating:
I wish every
programming language had a book like this. It is a unique work that will
make a Perl programmer a good Perl programmer. It's a compilation
of "items" that one usually only finds out with many years of
experience. It's not a ground-floor tutorial like the "Dummies" book,
but if you're going to learn Perl, you might as well learn to do it
right. This should definitely be the second Perl book you read.
Amazon customer review rating:
The undisputed "bible"
of Perl references. O'Reilly & Associates have long been the
standard in the Unix world with their "...in a nutshell" series. (So
much so that Amazon has a separate "O'Reilly Bookstore" on their site.)
Commonly referred to as "The camel book", this is a great desk reference
to have at your side when coding. While I wouldn't recommend this book
to someone looking to learn Perl, I can't imagine a serious Perl
programmer being without it. Amazon customer review rating:
If you're going to
Amazon to shop for something other than the above titles, please use
this link to go there.
Fact: A
recent study conducted by Sales and Marketing Executives
International concluded that 81% of major sales are closed after
the fifth contact.
Fact: 80% of people who
inquire about a product or service will buy it within one year of
their initial inquiry. However, more than 90% of the time, they
don't buy from the same company that they made their initial
contact with.
Now you can send unlimited
follow up emails with file attachments automatically from your
website. Make as many sequential letters as you need and send them
at the interval you specify. Unlimited autoresponders, Unlimited
follow ups, Unlimited users. One-click "remove-me" link.
Easy to set-up and configure in 10 minutes. EZ
-Response works without CRON jobs (which are not allowed on
many servers). It's simple, efficient, and Automatic!
