CGI and Perl Scripts

helmetpastoralSoftware and s/w Development

Dec 13, 2013 (3 years and 8 months ago)

116 views


1

CGI and Perl Scripts

.




CIS4930
-
AWD
-

2/9/04




http://cgi.resourceindex.com/Programs_and_Scripts/Perl/


.



Perl is the most commonly used language for CGI pro
gramming

on the www
.The
Common Gateway Interface (CGI)

is an essential tool for creating and
managing comprehensive web sites. With CGI, you can write scripts that create
interactive, user
-
driven applications.




.



Rather than limiting the Web to documents written ahead of time, CGI enables
web pages to be created on the fly, based upon the input of users. You can use
CGI scripts to create a wide range of applications, from surveys to search tools
,
from Internet service gateways to quizzes and games. You can increment the
number of users who access a document or let them sign an electronic guestbook.
You can provide users with all types of information, collect their comments, and
respond to them





A Typical CGI Interaction

-

Suppose
a guestbook
is created
for your website.
The guestbook page asks users to submit their first name and last name using a

fill
-
in form composed of two input text fields.
Figure 9
-
1

shows the form you
might see in your browser window.


Figure 9
-
1. HTML form

The HTML that produces this form might read a
s follows:

<HTML><HEAD><TITLE>Guestbook</TITLE></HEAD>

<BODY>

<H1>Fill in my guestbook!</H1>

<FORM METHOD="GET" ACTION="/cgi
-
bin/guestbook.pl">

<PRE>

First Name: <INPUT TYPE="TEXT" NAME="firstname">

Last Name: <INPUT TYPE="TEXT" NAME="lastname">


<IN
PUT TYPE="SUBMIT"> <INPUT TYPE="RESET">

</FORM>


2

The form is written using special
"form"

tags, as follows:



The
<form>

tag

defines the method used for the form (either
GET

or
POST
) and
the action to take when the form is submitted

that is, the URL of th
e CGI
program to pass the parameters to.



The
<input>

tag can be used in many different ways. In its first two invocations,
it creates a text input field and defines the variable name to associate with the
field's contents when the form is submitted. The f
irst field is given the variable
name
firstname

and the second field is given the name
lastname
.



In its last two invocations, the
<input>

tag creates a
"submit"

button and a
"reset"

button.



The
</form>

tag indicates the end of the form.

When the user pr
esses the
"submit"

button, data entered into the
<input>

text fields is
passed to the CGI program specified by the
action

attribute of the
<form>

tag (in this
case, the
/cgi
-
bin/guestbook.pl

program).

Transferring the Form Data

Parameters to a CGI program

are transferred either in the URL or in the body text of the
request. The method used to pass parameters is determined by the
method

attribute to the
<form>

tag. The GET method says to transfer the data within the URL itself; for
example, under the GET me
thod, the browser might initiate the HTTP transaction as
follows:

GET /cgi
-
bin/guestbook.pl?firstname=Joe&lastname=Schmoe HTTP/1.0

The POST method says to use the body portion of the HTTP request to pass parameters.
The same transaction with the POST meth
od would read as follows:

POST /cgi
-
bin/guestbook.pl HTTP/1.0


... [More headers here]


firstname=Joe&lastname=Schmoe

In both of these examples, you should recognize the
firstname

and
lastname

variable
names that were defined in the HTML form, coup
led with the values entered by the user.
An ampersand (&) is used to separate the variable=value pairs.

The server now passes the variable=value pairs to the CGI program. It does this either
through Unix environment variables or in standard input (STDIN).

If the CGI program is
called with the GET method, then parameters are expected to be embedded into the URL
of the request, and the server transfers them to the program by assigning them to
theQUERY_STRING environment variable. The CGI program can then ret
rieve the
parameters from QUERY_STRING as it would read any environment variable (for
example, from the
%ENV

hash in Perl). If the CGI program is called with the POST

3

method, parameters are expected to be embedded into the body of the request, and the
serv
er passes the body text to the program as standard input (STDIN).

Other environment variables defined by the server for CGI store such information as the
format and length of the input, the remote host, the user, and various client information.
They also
store the server name, the communication protocol, and the name of the
software running the server.

The CGI program needs to retrieve the information as appropriate and then process it.
The sky's the limit on what the CGI program actually does with the in
formation it
retrieves. It might return an anagram of the user's name, or tell her how many times her
name uses the letter "t," or it might just compile the name into a list that the programmer
regularly sells to telemarketers. Only the programmer knows fo
r sure.

A Simple
Perl
Program



The
perl

executable is normally installed in
/usr/bin

or
/usr/local/bin

.



Every Perl program must be passed through the Perl executable to be executed.
The first line in many Perl programs is something like
:
#!/usr/bin/perl

.



Command
-
line options such as the
-
w

switch, which produces warning messages.
.



For Unix systems, this
#!

(hash
-
bang or shebang)

tells the shell to look for
/usr/bin/perl

program and pass the rest of the file to
/usr/b
in/perl

for execution
.



Sometimes, different pathnames to Perl executable, such as
/usr/local/bin/perl
.
Might see
perl5

or
perl6

instead of
perl

on sites with older versions of Perl.

the "Hello, world" program in Perl:

#!/usr/bin/perl

print "Hello,

world!
\
n";



The Perl executable compiles the program internally into a parse tree and executes
it immediately. Because the program is not compiled and executed in separate
steps, Perl is commonly known as an
interpreted language
, but this is not true.

.




Unlike strictly compiled languages, the compiled form of a Perl program is not
stored as a separate file. However, Versions 5.6 and later give you the option of
using a standalone Perl compiler that creates
bytecode

to be executed separately.
.



Per
l "
script
" or Perl "
program
"? "
P
rogram
" is used to describe something that is
compiled into assembler or bytecode before executing, as in the C language.
"
S
cript
" is used to describe something that runs through an executable on your

4

system, such as the Bou
rne shell. For Perl, you can use either phrase
.



One performance hit for CGI programs is that the Perl interpreter needs to be
started up each and every time a CGI script is called. For improving performance
on Apache systems, the
mod_
perl

Apache module embeds the Perl interpreter
directly into the server, avoiding the startup overhead
.



When you write a Perl program
on a UNIX system
:
#!

line at the top of the
script
, ma
ke it executable with
chmod +x
, and
run it
.
.



On Win32 systems
, you can associate an extension (e.g.,
.plx
) with a file type and
double
-
click on the icon for a Perl script with that file type. Or, do this:


(ope
n a "DOS" window)


C:
\
> (edit your Perl program in your favorite editor)


C:
\
> pl2bat yourprog.plx


C:
\
> .
\
yourprog.bat


(program output here)

On Win32 systems
, if you double
-
click on the icon for the Perl executable, you'll find
yourself in a command
-
prom
pt window with a blinking cursor. You can enter your Perl
commands, indicating the end of your input with Ctrl
-
Z, and Perl will compile and
execute your script

Perl is arguably the most popular scripting language in use today. It is used for a wide
variety

of tasks, including file processing, system administration, web programming, and
database connectivity. Early Perl users had to be content with command
-
line interfaces or
full
-
screen interfaces using Curses or similar systems, but the splitting
-
off of the

Tk
widget library

(graphical
toolkit

called
Tk
) from
the
Tcl

(Tool Command Language)
language opened a whole new world to Perl. Perl
programmers could now easily create
graphical interfaces for their programs using Tk's flexible and friendly widget set

an
d,
with little effort, those programs could be made to work across Windows and Unix
platforms.

In our
Hello World example
, we'll have the title of our window say "Hello World" and
create a Button that will dismiss the application:

#!/usr/bin/perl

use Tk;

my $mw = MainWindow
-
>new;

$mw
-
>title("Hello World");

$mw
-
>Button(
-
text => "Done",
-
command => sub { exit })
-
>pack;

MainLoop;

The first line in
vokes Perl.


The second line tells Perl to use the Tk module. On Unix, that is. In Win32 you have to
type
perl hel
lo.pl



5

The third line:

my $mw = MainWindow
-
>new;

is how we create a window. The window will have the same basic window manager
decorations as all your other windows.

The title of our window is changed using the
title

method
.

If we hadn't used this
method
, the text across the top of the window would be the same as the name of the file
containing the code, excluding any extension. Using the
title

method is not required,
but it makes the application look more polished.

Any string we put as an argument becom
es the title. This is akin to using the
-
title

option
when starting any standard X Windows application.

The next line creates a Button widget, sets basic properties, and packs the widget.

The Button is set to display the text "Done" and to perform the Pe
rl command
exit

when
pushed.

Finally, the last item of concern is the
MainLoop

command. This starts the event loop in
motion, and from then on the application will do only what we have told it to do: if the
user clicks on the Button, the application will
exit. Anything else the user does

minimizing, resizing, changing to other applications

will be processed by the window
manager and ignored by our application
.



Figure 1
-
2. Hello World wi
ndow

The
sub

{

exit;

}

( or its equivalent,
\
&exit
) used to quit the Perl/Tk application. This
works fine as long as you have done a
use Tk
;

in the same file. Perl/Tk defines its own
exit

routine, which does some cleanup and various other things that are i
mportant to Tk.
The program is then unconditionally terminated, and control returns to the operating
system.

Another way to quit the Tk portion of the application is to call
$mw
-
>destroy
, which
destroys the MainWindow and returns to the code listed after
MainLoop
. This allows your
program to do post
-
GUI processing before exiting.


6

Table 1
-
1

lists widget types and suggested naming conventions for them. Replace "blah"
with a sensible description of the widget's purpose (e.g.,
exit
). If you use this
conventi
on, you'll always know what type of widget you're working with.

Table 1
-
1. Naming conventions by widget type

Widget
type

Suggested name

Examples

Button

$blah_b
,
$blah_bttn
,
or
$blahButton


$exit_b
,
$apply_b
,
$newButton


Canvas

$blah_canvas

or
$blahCanv
as

$main_canvas
,
$tinyCanvas

Checkbutton

$blah_cb

or
$blahCheckbutton

$uppercase_cb
,
$lowercaseCheckbutton


Entry

$blah_e

or
$blahEntry

$name_e
,
$addressEntry

Frame

$blah_f

or
$blahFrame

$main_f
,
$left_f
,
$canvasFrame


Label

$blah_l

or
$blahLabel

$name
_l
,
$addressLabel

Listbox

$blah_lb

or
$blahListbox

$teams_lb
,
$teamsListbox

Menu

$blah_m

or
$blahMenu

$file_m
,
$edit_m
,
$helpMenu


Radiobutton

$blah_rb

or
$blahRadiobutton

$blue_rb
,
$grey_rb
,
$redRadiobutton


Scale

$blah_scale

or
$blahScale

$age_scale
,

$incomeScale

Scrollbar

$blah_scroll
,
$blah_sbar
, or
$blahScroll


$x_scroll
,
$yScroll

Text

$blah_t

or
$blahText

$file_text
,
$commentText

Toplevel

$blah_w

or
$blahWindow

$main_w
,
$fileopenWindow

A GUI often makes the application look much more polished
and purposeful than a
command
-
line interface does, but it's easy to go overboard with a GUI and end up with
something ugly, clunky, and impossible to navigate. So here are some things to consider
when deciding how the GUI should look:



Every widget should
have a purpose that is intuitive and informative.



Think about the way a user will use an application and design accordingly.



Don't try to cram everything your application does into one window.



Don't always try to separate everything into different window
s. Sometimes the
application is so simple that one window is all you need.



Colors are great, but there are a lot of color
-
blind people out there. The same
applies to fonts: many folks cannot read very small fonts. If you insist on using
color and particul
ar fonts, allow them to be customized via the resource database,
through a file, or through the application itself.



Some widgets do their jobs better than others. Use the proper widget for the job.