Setting up Perl
Perl is the name both of a language (the Perl programming language) and a product (the implementation of the Perl language). In general, in this book 'perl' is used to denote the perl language interpreter or compiler; capital 'Perl' is the language.In this chapter you will learn where to get hold of information and source code for perl and its extensions, see how they slot together to provide a Perl programming environment, and learn how to set up a working Perl/Tk installation.
This chapter does not teach you anything about the Perl language; it's all about the perl implementation, and how to configure and install it. This information is essential if you are getting started with Perl and don't already have a working perl kit. If you have an account on a computer with a working Perl/Tk kit, you may want to skip the second half of this chapter (from ``Getting and Installing Perl'' onwards) and go straight into Chapter 3.
The Perl language was originally developed by Larry Wall; it is maintained by him in conjunction with a group of Perl specialists who coordinate via an email list called 'perl5-porters'.
The Perl implementation is distributed as free software. Perl is copyrighted software, and its authors don't waive their rights to it; but they want to make it available without restriction, and this is explicitly stated in a document called the 'Artistic License' which is distributed with the Perl source code. 'Free software' in this context means that anyone can get hold of the source code for Perl and use it, with the one proviso that restricting its distribution is forbidden. You can compile a copy of Perl and sell it if you want (and if you can find anyone willing to pay for it), but you can't stop other people giving it away or selling it. And as the definitive implementation of Perl is free, no software company has yet bothered writing and marketing their own proprietary Perl language implementation.
Some companies do sell copies of Perl. Cygnus Support (http://www.cygnus.com/) will sell you a copy for various UNIX platforms, and will provide technical support and upgrades. Mortice-Kern software include a copy of Perl in their commercial package of UNIX tools for DOS and Windows. The willingness of these companies to support Perl users in the field provides essential reassurance for IT managers who are not allowed (for reasons of site policy) to use a product for which no commercial support contract is available.
Even if you don't buy a commercial copy of Perl, an excellent level of support can be obtained from the Perl user community. Perl's history, development, distribution, and support is all intimately tied up in the internet. Several newsgroups exist for the discussion of Perl programming, Perl modules, and Perl/Tk development. In addition, mailing lists exist for specific Perl modules, the Perl Porters (who ensure cross platform compatability, bugfixes, and some enhancements), and specific Perl ports (such as the MacPerl and WinPerl versions). A handful of extremely comprehensive web sites exist; and finally there is CPAN, the Combined Perl Archive Network, a large distributed information and source code repository which exists at several locations on the internet.
- NOTE
-
Almost all the Perl resources mentioned in this chapter are available over
the Internet. It is assumed that you have access to a working internet
connection and a Web browser with which to obtain files. It is also assumed
(as mentioned in the introduction) that you are working on a UNIX system.
Where appropriate, resources for other platforms are noted.
Perl internet resources
Your first venture into the world of Perl should probably be a session of internet surfing.At least three web sites exist which are of direct interest to Perl programmers. These are:
www.perl.com is maintained by Tom Christiansen (co-author of 'Programming Perl 5', specialist Perl consultant, and one of the mainstays of the Perl community). The site includes a full set of documentation, including material not available elsewhere, and a mechanism for pointing web surfers at the nearest mirror of the CPAN archive.
CPAN, the Combined Perl Archive Network, is a structured set of directories containing approximately 250Mb of miscellaneous Perl material (at the time of writing). It is mirrored at approximately twenty locations: you can find the nearest to you via:
http://www.perl.com/CPAN/CPAN.html
CPAN sites are usually accessible via both HTTP (hypertext transport protocol, used by the World Wide Web) and FTP (file transfer protocol). See, for example:
http://www.doc.ic.ac.uk/packages/perl/CPAN/
CPAN is split into a number of distrinct directory trees. One of these, source/, contains the source code to the current (and some previous) Perl distributions. As Perl is implemented in C, you will need a full C compiler and libraries to make use of them. Another (ports/) contains ports of Perl to other operating systems (including Windows NT, DOS, OS/2, and MacOS). These are generally provided as both source code and compiled applications. (Most UNIX systems are sold with a bundled C compiler and programmer's workbench; other operating systems, however, don't usually expect users to have to compile software for themselves in order to install it.)
In addition to the Perl source and ports, CPAN contains a wealth of supplementary material; modules, programs, documentation, and miscellaneous bits and bobs.
The CPAN directory tree looks like this:
- indices
-
Directory containing various listings of the contents of the rest of CPAN.
- ports
-
Contains subdirectories corresponding to each architecture type for which a
port of Perl exists. Check in the subdirectory for a binary distribution or
source code to a version of Perl for a specific platform. (Platforms
include Amiga, Atari ST, Macintosh, OS/2, VAX/VMS, Windows NT, MS-DOS, and
even a Perl 4 port for MVS).
- scripts
-
Contains perl scripts for various tasks which have been contributed to the
CPAN archive. Arguably this is the weakest section in organizational terms;
much of the material here dates back to Perl 4, and it is not as
effectively catalogued or maintained as the module hierarchy described
below. In fact, with the switch to the modular structure of Perl 5, this
section should probably be considered obsolete. Nethertheless, some of the
items in this directory tree may help you with standard off-the-shelf
tasks.
- doc
-
Contains a huge quantity of documentation for Perl and various Perl
modules. The sections to note are as follows:
- faqs
-
Answers to Frequently Asked Questions. These are question-and-answer files
accumulated by the participants in various usenet newsgroups, and are
intended to answer the commonest questions that repeatedly come up there --
the issues that all new programmers run into sooner or later. The FAQ files
here include those for Perl, and for Perl/Tk, plus various other
supplemental information. It is sensible to start in the subdirectory
/docs/faqs/meta, which contains the meta-FAQ: where to go to find answers
to your questions.
- fmteyewtk
-
Far More Than Everything You've Ever Wanted to Know About... a series of
essays posted to comp.lang.perl.misc over a period of a couple of years by
Tom Christiansen. In each essay, he gives an in-depth, usually highly
technical, exposition about a specific aspect of Perl 5 programming. For
example, the file ``slices'' goes into great detail on the pros and cons of
array slices (which are described later in this book). Best thought of as
'advanced' FAQ's, much of this material has resurfaced in ``Programming
Perl 5''.
- manual
-
The Perl reference manual. Perl was originally developed as a UNIX
application; it was also documented in a traditional UNIX 'man page', a
reference manual that followed a strict format and which was intended for
documenting the usage of a UNIX command-line tool. As of Perl 4, the man
page had grown to some 90 pages; with Perl 5, the manual has been split
into twenty or so subsections which run to 300 pages when printed out. This
directory contains versions of the Perl reference manual in a variety of
formats, including HTML (for viewing via a web browser), postscript (for
printing), and POD (plain old documentation) format, Perl's native
documentation sublanguage.
- relinfo
-
Information about the current release, including release and installation
notes.
- rtfm-mirror
-
A mirror archive containing the Perl FAQ's stored on rtfm.mit.edu, a large
internet server that acts as a central repository of FAQs for all
newsgroups that have them.
- pod2x
-
Translation software that reads in POD documentation and converts it into
other formats, such as HTML, FrameMaker MIF, troff (man macro format), and
TeX.
- refguide
-
Earlier versions of the Perl reference manual.
- clpa
-
An archive of all postings to comp.lang.perl.announce, a moderated usenet
newsgroup reserved for announcements of Perl-related software. The archive
consists of gzip-compressed tar files, each of which contains a set of
usenet messages. Comp.lang.perl.announce is the usual place for announcing
availability of new Perl modules, release of software written in perl, new
ports, patches, upgrades, and revised releases. Most material announced on
c.l.p.a finds its way into CPAN, but not all: the clpa directory is thus a
useful index to all announced Perl resources on the internet.
- authors
-
Perl modules that have been released publicly via CPAN are all registered
centrally in the Perl module registry. The modules are identified by
author; each author with a registered module has a home subdirectory
beneath this directory, and can place their module (or updates to it) in
this area.
- modules
-
This is the main directory tree for finding modules. UNIX permits symbolic
links; that is, stub files that 'point to' an underlying entity elsewhere
in the filesystem. The modules hierarchy is a link farm -- a set of
directory trees that act as an index for the CPAN module list. At the
bottom of each category can be found one or more symbolic links, pointing
to modules filed under their author's home directory.
The simplest way to find a module, if you know what you are looking for, is to read the long HTML version of the module list; this contains an entry for each module (by category), and a link to the author's home directory. Alternatively, you can descend directory trees organized by module name or module category, or examine a couple of other directories containing links to related material (for example, database related modules).
- NOTE
-
The 'tkperl' distribution under modules/misc/ should not be confused with
Perl/Tk (which can be found under by-category/08_user_interfaces/tk/).
'tkperl' is an obsolescent partial port of Tk 3.6 to Perl 4; it is no
longer supported by its developer (Malcolm Beattie) and has been replaced
by Perl/Tk. Most of the material and exercises covered in the later
sections of this book will break if attempted using tkperl.
- faq
-
The Perl FAQ files, broken down into sections for access via a web browser;
equivalent to the FAQ files stored under docs.
- incoming
-
Used for new file uploads to the archive.
- src
-
Source code for the current Perl release (and the previous stable version:
currently Perl 5.003 and Perl 4.036).
- misc
-
Assorted supplementary material; Emacs modes for editing Perl files, Perl
definitions for Vgrind (a literate programming tool developed by Donald
Knuth), GIF and XBM graphic files of the original perl book covers, a
purity test for Perl programmers, and some humorous quotes and ``Just
Another Perl Hacker'' signoffs from Larry Wall and Randal Schwartz.
- nutshell
-
Programs and code fragments from the Nutshell books ``Programming Perl''
(Wall and Schwartz) and ``Learning Perl'' (Schwartz), published by O'Reilly
and Associates.
Getting and installing Perl
As mentioned above, for UNIX systems Perl is distributed in source code form. To install Perl on a UNIX system, it is necessary to download and unpack the source code, then compile it using a C compiler.If you are installing Perl on a Macintosh or PC running a Microsoft operating system, you can make use of a precompiled binary distribution. (This goes for most non-UNIX systems).
However, it is important to note that a proper Perl installation consists of much more than just a program called ``perl''.
For Perl to work effectively, with all its facilities available, various supplementary material is needed:
- documentation
-
typically consists of the POD files for the Perl reference manual, possibly
also UNIX man page source
- Perl header files
-
These files (suffix: .ph) contain system-specific constant information that
enables suitably-written Perl applications to run on a variety of
platforms. This is an old mechanism (from Perl 4), but some .ph files may
be required for older programs to run.
- Perl modules
-
These files (suffix: .pm) contain chunks of Perl source code that may be
called by Perl programs to perform specific tasks. A standard library comes
with the Perl distribution, containing modules that are presumed to be
available on any system running Perl; they support the development of new
Perl modules, networking, internationalization (I18N), and other
architecture- specific operations.
- Perl programs
-
These files (usually identified by the suffix .pl) are standard tools that
are supplied with a Perl distribution. It's a bad idea to delete them --
other perl programs may rely on them for one function or another, and
they're often useful as programming examples.
- Dynamically Loadable Libraries
-
These files (no particular suffix) provide extensions to the core language
facilities compiled into Perl. Versions of Perl (on operating systems that
support dynamic loading) can load external chunks of pre-compiled code on
demand, for example to talk to a database engine, to provide POSIX API
calls, or to provide a graphical front end. pTk is one such dynamically
loadable library. Systems which don't support DLLs aren't left out; but
support for these extensions has to be linked into the Perl application
when it is first compiled. That makes the Perl program bigger, slower to
load, and more cumbersome (as not all perl scripts will need to call on all
the extensions).
- Perl programs
-
These files (suffix: .pl) are standard tools that are supplied with a Perl
distribution. It's a bad idea to delete them -- other perl programs may
rely on them for one function or another, and they may be useful as
programming examples.
-
Download the latest Perl source code distribution. This is a UNIX tar
archive (suffix: .tar), usually compressed using the public domain gzip
program (suffix: .tar.gz or .tgz). Uncompress the archive, and unpack it
somewhere sensible (such as /usr/src, on a Linux system, or /opt/local/src on Solaris).
The Perl archive expands into a directory tree. Go to the top level, and make sure you're logged in as root; if not, you won't be able to install perl into the system directories. (You can still build perl and install it in any directory you own, but it's a little unproductive to install a separate copy per user.)
You should read the text files README and INSTALL before you go any further. (Of course, you probably won't ...)
-
Perl is intended to compile on a wide range of architectures.
Many of these differ so widely that the same source code cannot be used on all systems; so the first step is to run a shell script called ``Configure''. Configure checks your computer, makes sure that you have all the tools you need in order to build perl, and looks up the various system libraries that the perl build process uses to make sure they're there -- if not, Configure will attempt to use some pre-canned alternatives.
Configure can be run interactively -- if you know a lot about your operating system's guts -- but the first step is usually to invoke it non-interactively: just type:
./Configure -des
Configure will blast through its checks without asking questions, working on the assumption that you want to put everything in the default installation directory perl5/ (typically under /usr/lib, but possibly somewhere under /var or /opt or /usr/local/lib/.).
- NOTE
-
Configure reads its default settings from a file called config.sh. If one
of these exists in the source directory before you begin building perl,
better delete it unless you're sure you want Configure to use it. (If you
know what you're doing you can edit config.sh by hand, but this is not
recommended unless you're an expert.)
-
There is a directory, 'hints/', in the Perl source distribution. This
contains hint files specific to a wide range of different operating
systems. Configure tries to work out what operating system you're running
and looks in 'hints/' to see if there's a file for it. If there is, it uses
this to override some default settings. If you are running something common
like Solaris or Linux or FreeBSD, the hints file for your system should
permit a clean build; if you're running something really obscure or trying
to compile for the first time on a new operating system version, you may
have to do some digging.
When preparing to build Perl/Tk, it's important to try and make sure that dynamic loading is available. Otherwise you'll have to build a separate 'tkperl' binary program, and your usual perl binary won't run Perl/Tk scripts. To check this, build perl then run the script ``myconfig'' in the source distribution; in its output, look for the section ``Dynamic Linking''. Alternatively, poke around in the hints file specific to your architecture; there will probably be some settings for dynamic linking in there, along with suggestions about enabling it.
-
Configure, if it succeeds, spits out a Makefile.
A Makefile is a set of commands that drive the UNIX program ``make''. Make is a dependency analyser; the perl program is built from several sub-components, each of which in turn depend on sub-sub-components. Make keeps track of dependencies and ensures that each file that needs to be compiled is only compiled once, by working out the best order feed them to the compiler in.
When Configure finishes, just type:
make
Make will run, look for a file called Makefile containing the dependency information it needs, and begin throwing source code at the C compiler.
At this stage it is a good idea to go and have a cup of coffee, unless you're working on a blisteringly fast server. Perl consists of some 60,000 lines of code: an optimizing compiler will take a while to munch on it, and Perl needs to be optimized -- if it isn't, your programs will run slower.
- NOTE
-
If make fails, you are liable to see a series of error messages emitted by
the compiler, then nothing. At this point, some experience of debugging
UNIX applications in C comes in handy; you have just gone outside the remit
of this book. A few clues are in order, though.
- a
-
Always double-check your config.sh file to see if it accurately represents
the state of your computer.
- b
-
It is a bad idea to try building Perl with only 5Mb of disk space free.
(Perl is large.)
- c
-
Every system has its quirks. If you are working on Solaris 2.4 or 2.5, for
example, you should ensure that /usr/ucb/bin
appears in your PATH environment variable after /opt/SUNWspro/bin and /usr/ccs/bin
(or wherever your C compiler lives); this is because the tools in /usr/ucb/bin are provided for backward compatability with SunOS and don't do what Perl
expects them to do. If you have the bad luck to be trying to install on a
Sun Netra web server, forget it: the system lacks essential shared
libraries required by Perl -- you can't even get the Sun SPARCcompiler kit
to run properly on a Netra. The wrinkles are potentially infinite: the best
solution is to ask someone who is an expert on the care and feeding of your
platform.
- d
-
If ./Configure -des results in a bad compilation, save a copy of the config.sh file and run
Configure without the -des flags; that is, interactively. It will take
longer, but you may be able to deduce the cause of the malfunction because,
for each setting, Configure always shows you its current default value when
prompting you to input a new one.
-
After running make, you should have a file in the source directory called
perl. This is the perl binary. But does it work? The Perl distribution
comes with a set of regression tests that exhaustively test a new perl
binary for conformance. All perl binaries should give the required results
when running each test in the suite; otherwise something went wrong in the
build process, and your local perl contains a bug.
To run the regression tests, type:
make test
The tests are driven by a Makefile. As each test runs, perl reports its results; at the end, it tells you how close to the specification your copy lies.
Note that some platforms cannot pass the regression test suite, whatever you do. For example, MachTen (BSD 4.3 running on a Mach micro-kernel on top of MacOS) does not support hard links; thus, some of the filesystem tests almost inevitably fail when building Perl on MachTen. Again, DosPerl will automatically fail the tests concerned with forking and exec'ing child processes -- DOS simply doesn't support those facilities.
-
Once you have built a perl binary and tested it, you need to install it. By
default, Configure designates
/usr/lib/perl5 as the place to put all the perl libraries, and /usr/bin as the place to install the binaries. (If you ran Configure interactively
in step (3) above you may have been able to change these.)
To install Perl, type:
make install
The makefile uses standard UNIX utilities to create the appropriate directories, copy the files into them, set their access permissions, and translate the documentation from POD format into standard man pages.
If you got this far with no errors, then you have a fairly standard Perl installation on your computer. It is then time to install some Perl modules, and build and install pTk. Don't be surprised if you don't get it right the first time; building and installing Perl/Tk is non-trivial, and although 'canned' binary distributions are available for many platforms, the process of compiling your own development environment is still one of the biggest hurdles to leap when getting to grips with Perl. (In fact, it's possible to become a highly proficient perl programmer and still not be able to do a successful install -- let's hope that as time goes by, Perl is distributed as standard with more systems, so that this irritating process becomes less important.)
Installing CPAN modules
Now we've installed Perl, why not go straight on and install Tk?That would seem like a logical course, but first it is useful to see how Perl modules are installed.
Modules (distributed via CPAN, under the authors/ directory) are packaged in compressed tar files (.tar.gz).
Many modules consist of Perl module source code (.pm) that needs to be installed in /usr/lib/perl5, or wherever your Perl libraries live. Because they're not part of the standard distribution, modules you install by hand go in a subdirectory: /usr/lib/perl5/site_perl.
Some modules contain C source code for dynamically loadable libraries, as well as the perl module that loads them. These libraries need to be compiled and are installed in a subdirectory that is architecture-dependent; that is, because libraries compiled on one platform may not run on another platform (even under the same operating system), they go in a subdirectory indicated by the machine architecture type: for example, /usr/lib/perl5/site_perl/i586-linux/. (i586-linux is the machine architecture in this example instance.)
Most modules intended for general distribution are packaged in such a way that a site-specific Makefile to control their installation can be generated using a utility called the MakeMaker. (If you've installed the Perl man pages, try typing:
man ExtUtils::MakeMaker
for a detailed description). Such modules unpack from their tar archive into a standard directory tree, including subdirectories blib/ and lib/, and sometimes others including bin/ and t/. In the root of this directory tree can be found some standard files: MANIFEST (a list of the contents of the module) and Makefile.PL. Makefile.PL is not an input file for make; rather, it's a perl script that loads the MakeMaker utilities, checks that everything necessary to install the module is present, and prints out a Makefile. The MakeMaker tools merge any site-specific information (such as the local configuration of your Perl kit) with the module's instructions for where it needs to be installed. The output Makefile is thus a set of local specifications for where the module should be installed. Thus, the process of installing a module is like a microcosm of the main Perl installation, using Makefile.PL instead of the Configure script.
To install a module:
-
Unpack it
-
In the module's root directory, type:
perl Makefile.PL
(If such a file exists -- if not, look for a file called README or INSTALL and follow the instructions).
-
Type:
make
-
Type:
make test
(If any test programs are included, they will be executed.)
-
Type:
make install
(The module will be transferred to the directory site_perl, beneath your local perl installation directory)
The pTk distribution (as of Tk-402.002) requires some other modules in order for all its components to work correctly. Before installing pTk, you will need to install some of the following modules:
- News::NNTPClient
-
(tools for receiving usenet news feeds)
- LWP
-
(libwww-perl; a library of WWW tools)
- MailTools
-
(tools for processing SMTP mail messages)
- Net-SMTP
-
(tools for handling SMTP mail transport)
- Net-Domain
-
(tools for resolving domain names)
Getting and installing pTk
PTk is another Perl module, and can be found on CPAN in the directory authors/id/ni-s/. (ni-s is short for Nick Ing-Simmons, the primary developer and maintainer of pTk.)At the time of writing, the latest version is tk-402.002; that is, Tk 4.2, release 2. This is based on version 4.2 of Ousterhout's Tk library. Tk is now at version 8.0 (although this is only one release up from 4.2 -- Ousterhout skipped several digits to bring the Tk versioning into line with Tcl.)
To install pTk, you need to have a UNIX workstation with the X windowing system: preferably X11R5 or X11R6 (release 5 or 6) and the Xlib library. As X11 is effectively free, most modern workstations come with this software. In addition, it is useful to have a Perl kit installed that supports dynamic loading.
(Early versions of Perl/Tk for Windows 95/NT are becoming available; these are binary distributions, so the following instructions are not relevent. A version of Perl/Tk for MacOS is not yet available, but if you have MachTen you can install the UNIX Perl/Tk kit and use that.)
Tk-402.002 is installed much as any other Perl module.
-
Unpack it in a directory outside the Perl source directory tree.
-
Inside the root pTk directory, type:
perl Makefile.PL
This generates a makefile.
-
Type:
make
To compile the Tk library and configure the pTk perl module.
(Note that it takes a lot longer to make pTk than most other Perl modules -- not surprising, considering that Tk-b11.02 contains 205,000 lines of C source code -- nearly four times the size of Perl 5 itself!)
-
When make finishes, type:
make test
This should (if all goes well) cycle through the source directories, then throw up a screen like this:
This is the test suite for Perl/Tk -- a test application that actually invokes most of the working subroutines required for Tk. If this program runs, then pTk has built itself correctly for your system.
- i
When you're happy that pTk is sane and smart, type:
make install
To install it in the right place (typically /usr/lib/perl5/site_perl/Tk).
- NOTE
-
If pTk fails to build, you're in much the same position that you're in if
perl fails to build following a Configure -des command. Things to suspect:
- a
-
Missing X libraries. Tk is pretty fussy about wanting a recent version of X
windows, with appropriate libraries. Tk builds on top of the Xlib libraries
and requires a shareable image libX11.a or libX11.so, and the header file
Xlib.h.
- b
-
Statically linked perl. If you build a statically- linked perl, you won't
be able to use a dynamically- loadable Tk library; you'll need to build a
static tkperl (perl with all the Tk bits linked in).
- c
-
Are h2xs and xsubpp working? These are two programs distributed with the
perl kit; they allow dynamically loadable extensions to perl (with 'glue'
written in the XS sublanguage) to be linked with C header files for
compilation on a local platform. If they're missing, you'll find it hard to
build dynamically loadable extensions for perl.
- d
-
Another hint: on Linux (possibly the commonest UNIX- like platform by now,
given its cost and availability) it really helps to have a kernel that can
load ELF binaries and a compiler (GCC) which can generate them. (It is
especially un-helpful to have a compiler which produces only ELF binaries
and a kernel that can only only load a.out binaries, or vice versa.)