![]() ![]() |
![]() ![]() |
![]() ![]() | |
© 1997 The McGraw-Hill Companies, Inc. All rights reserved. Any use of this Beta Book is subject to the rules stated in the Terms of Use. |
The goal of this chapter is to introduce you to Perl and show you how to use Perl effectively. A large part of using Perl effectively is getting it installed on your system correctly. Getting Perl installed is only the first step. You also need, or should know how to find information on:
customizing Perl for your particular situation
places where you can get answers about Perl questions
places to talk with experts about Perl
(maybe) professional Perl support and training
Finally, you need to be able to use the documentation for the day to day programming issues that you will run into. Perl has some of the best on-line documentation available anywhere, whether in commercial or freeware packages. You should be able to easily consult it for problems that you will bump up against. It is the purpose of this chapter to orient you with all of these resources, as well as be a quick pointer to where you can find more information.
In this chapter we will go through each of the steps that most people go through in setting up Perl for use on their operating system. We start with the first Perl programming decision: are you going to be using an already installed Perl, or installing a new version? Each has its benefits and drawbacks.
We take each decision point in turn. First, we give you instructions on how to find an already installed Perl on UNIX, NT/Win95, Macintosh, OS/2, and VMS, and tell you what to look for in these installations.
Second, we look at installing Perl from scratch on the same five operating systems, as well as giving instructions on how to test your new Perl, and what to look for in the installation. Third, we look at installing Perl modules, and customizing the installation with modules that people have written on the net. These canned solutions include CGI, making Graphic User Interfaces with perl/TK, and so forth. Fourth, we look at the Perl documentation, how to use it, and how to print it out in formats such as html, postscript, man, and just plain text.
Finally, we look at the basic Perl support that exists on the Internet. We will be fairly parsimonious here, only noting the basic items of which you should be aware.
Perl is truly a language that is a 'living, breathing entity'. No formal committee decides on what is best for the language. People who actually use the language decide on its content. Hence, there are always developments, changes, and new news in the Perl community, and it is quite exhilarating to be a part of it. Getting into the Perl flow is part of learning the language effectively.
Perl has been ported to pretty much every platform around, so there is no possible way that we can cover all the platforms here. You can get Perl 5 working on almost every flavor of UNIX, Windows NT, Windows 95, Win3.1, MS-DOS, VMS, MacOS, plan9, AS/400, and mainframes running MVS,(or OS/390), and, probably by the time this is in print, VM/ESA. In fact, if you are a mainframe programmer and want to get an idea how UNIX will feel, learning Perl is the ideal way. Likewise, if you are a UNIX programmer who wants to test the waters with NT, learning Perl is the ideal way.
Perl is so widespread*, we will have to be picky in which operating systems we cover. We shall cover the installation of Perl on:
*
*
We have not begun to mention all the systems Perl supports. Some others: AmigaOS, Atari, VOS, Next, Machten, lynxOS, and a bunch of systems that I haven't even heard of: mpe, acorn, aos, etc., etc., etc. * |
If you are using one of the operating systems which I do not cover, I strongly suggest that you join the mailing list for your particular OS. Most of the examples in this book should work on these operating systems, but I cannot vouch for them all. This book is only guaranteed (as much as anything in the world of computers is guaranteed) for Windows NT, Windows 95, and the thousands of UNIX variants out there. With a few exceptions that are labeled, all of the examples should work transparently between the Windows and UNIX platforms.
There two basic choices on how to proceed. You can:
1) find an already installed Perl
or
2) build one out of the box, either by downloading a Perl executable pre-built or building it yourself
For the purposes of finding and/or installing Perl below, we will pretty much start from scratch. We will be going over the things you need to type from scratch up until the point that you have installed Perl correctly. Why? Perl is an Esperanto language, meaning it pretty much looks and feels the same, everywhere. Hence, one of the great reasons to use Perl is to get yourself familiarized with an unknown environment, whether your 'unknown environment' is UNIX, NT, VMS, or whatever.
If you compile Perl on any one of those systems, your woes about learning that Operating System are about 90% over. This means that we will assume that you are a new user on the system on which you are going to install Perl. If you are not, then you probably will not need to read the text below!
Perl has been installed almost everywhere, and using pre-installed Perl has several advantages:
1) maintainability: You don't need to maintain Perl yourself. If you have any difficulties, you can ask the system administrator.
2) centralized administration: you can ask the person who installed Perl to extend or update the copy of Perl.
3) traceability: if lots of people are using Perl, they can all use one copy rather than having individual copies lying around. If you are debugging other people's programs, you can guarantee it is not an error due to Perl's version.
4) low overhead: in fact, you don't need to do anything as far as installation is concerned.
Likewise, though there are disadvantages:
1) loss of control: if you want to update Perl yourself, you can't. Usually Perl is in a centralized place, such as '/usr/local/bin' on UNIX, and can only be modified by a system administrator. This means you need to ask the powers-that-be if you wish to modify it.
2) loss of flexibility: you are at the mercy of whatever version of Perl and options that the system administrator has installed. Perl has options such as a debug option, to use different compilers and so forth. This is an increasingly important concern if you want to use the latest version of Perl, because many sites want to play it safe and use an older version.
In other words, if you use an existing Perl, you are passing the responsibility of maintaining Perl to the system administrator. In doing so, you lose some of the freedoms that you would have if you installed it yourself. Of course, how much freedom you lose depends on the operating systems that you install it on; larger, more scaleable systems (Plan9, UNIX, VMS, NT) will benefit more from custom installation.
If you decide to use an already installed Perl, you have to find it, and make sure it is the correct version of Perl. Your goal in finding Perl is twofold. One, you are going to want to find out which version of Perl is installed. Two, you should find out where Perl is installed. Finding Perl on a system is a somewhat system dependent task, so let's go over each system.
To find out which version of Perl is installed, you can simply say something like:
prompt% perl -v
in which '%prompt' is your command prompt, and 'perl' is the most common default name for the Perl executable. If this fails, other commands you can use are:
prompt% perl5.00X -v
or
prompt% perl5 -v
where 'perl5' and 'perl5.00X' (X being a number) are other, common, alternative names for the Perl executable.
After this, you can use whence, or which, to tell you where the Perl executable is installed. This,
prompt% whence perl
would give you the complete path to your Perl executable. If this doesn't work, try
prompt% which perl
because whether your system has whence, or which is system dependent.
These commands will only work if Perl is in your path, if your system setup includes the directory where Perl is installed. If you do not have any luck finding it using the commands above, you can use some extremely common system commands on the UNIX platform to find Perl. find, for instance can locate Perl easily. The following command:
prompt% find / -name "perl*" -print -perm -550
will find all files on your system that begin with the string 'perl*' and are 'executable' by you ('-perm 550'). Hence, it finds Perl executable candidates. You can also look in some centralized places for Perl. Common central locations for UNIX are /usr/bin, /usr/local/bin, and /usr/sbin.
If you find Perl this way, and it was located in the directory /usr/local/bin, say something like:
prompt% /usr/local/bin/perl -v
to get the version of Perl. Then, add to your path variable something like:
PATH=$PATH:/usr/local/bin
which will now let you execute 'perl' without having to type '/usr/local/bin' in front of it all the time. In any case, you are aiming for a window that looks something like Figure 1.1:
UnixVersion.PNG
Figure 1.1
Output of a Successful Version Check on UNIX
If you see this, then you know you are on the right track.
There are a couple of ways to find Perl on Windows NT. One is from the command line. Open up a DOS shell and type:
C:\> perl -v
which, again, will check to see whether Perl is installed in the centralized place, and whether or not the executable directory has been added to your path. You can also say:
C:\> \perl\bin\perl -v
in case Perl is installed in the regular place, but not yet set up in your path. Note that you are going to want to save the information about which version of Perl you have, which is the output of this command.
You can also search for Perl on your whole disk drive by saying something like:
C:\> dir perl* /s
or going into Explorer and doing a 'find' for files named 'perl'. If it is a non-standard place, write that place down, and then add it to your path by saying:
set PATH="%PATH%";C:\path\to\perl\binary
where '\path\to\perl\binary' is the name of the Perl binary. (This is so that you do not need to type the full path to Perl each time to run Perl scripts.) In any case, after setting the PATH variable, the command:
C:\> perl -v
should give you something like what you see in Figure 1.2:
NTVersionCheck.PNG
Figure 1.2
Successful NT check for Perl
which again, indicates what type of Perl you have.
Unlike Windows and UNIX, Macintosh has a GUI interface that is used to run Perl. It is called the "MacPerl" application. (There is a command line version of Perl that comes with MPW - a professional command line Mac development tool - but the most popular way is through the GUI with MacPerl.)
Finding the MacPerl application is like finding any other file on the Mac. Simply go to the 'Find' option in the system 7 tool, and look for the string 'MacPerl'. If you find MacPerl, you are going to see a distribution that looks something like Figure 1.3:
MacDirectory.PNG
Figure 1.3
MacPerl directory structure
This software has gotten the award for the 'coolest icons' in the Perl world.
In order to find out which version of Perl you are going to want to run, you double click on the MacPerl icon (the one with the camel), and go to the 'Script' sub menu. Choose 'one liner' and type as shown in the dialog box in Figure 1.4:
OneLiner.PNG
Figure 1.4
Command to get version of Perl
This will give you the display shown in Figure 1.5:
MacVersion.PNG
Figure 1.5
Successful Macintosh check
Note that the Macintosh version of Perl is unlike every other version that is discussed here, as it is only up to perl5.002.
Also note that you may find a different version here, the MPW version. This version is Perl in a command line environment. It works with the Macintosh Programming Workshop. If you want to use that version, you are going to have to get MPW. The easiest way to do so is to go to Metrowerks
http://www.metrowerks.com
and order it from there through a package called CodeWarrior.
Metrowerks provides a very UNIX-like command line environment, along with a complete development kit to write C (and Perl) programs without the overhead of a GUI.
Finding Perl on OS/2 is pretty much like finding Perl on the UNIX's and Win32. All you need to do is get a shell under the 'command prompts' folder, and type
[H:] perl -v
Then, if the Perl binary is in your PATH, you will get information on which Perl you have installed. Just as in UNIX or NT, if you can't find Perl this way, you can do a 'find':
[H:] find "perl*" .
which will show all of the files named Perl on your system. When you find the correct binary (Perl.exe), then you can say:
[H:] set PATH="%PATH%";\path\to\perl\executable;
which will then set it so your environment can find Perl automatically. Typing:
[H:] perl -v
should then bring up a screen looking like Figure 1.6:
OS2PerlVersion.PNG
Figure 1.6
Perl version for OS/2
This, again, indicates you are on the right track. Check to see that you have the correct version number of Perl, and go from there.
Finally we shall consider locating Perl on VMS versions 6.2 and above. If you are sitting down at a DCL prompt (if you are a UNIX user, the shell equivalent in the VMS world), type:
$ perl -v
just like any other OS to show you the Perl version. If you want to see where the Perl is located, on disk, you can say:
$ show symbol perl
PERL == "$PERL_ROOT:[000000]PERL"
which shows, in VMS-ese where PERL is installed. (If you are unfamiliar with VMS, $PERL_ROOT is a logical, which means that it hides all of the physical details about the computers, paths, etc., where Perl is installed. The '$' indicates that it is a binary executable.). And:
$ show logical perl_root
"PERL_ROOT" = "DKA600:[PERL5_004_01.]" (LNM$PROCESS_TABLE)
gives you a more concrete look at where Perl actually is (DKA600 is a 'device' or disk-drive, PERL5.004_01 a directory).
Finally, if nothing seems to be working, say
$ DIR DISK:[*...]perl
where 'DISK' is the disk drive(s) that to get where the Perl executable is located. This must be typed separately for each and every disk. A Perl script does this very nicely, so you can use older versions of Perl to 'piggyback' the installations of newer ones.
Then set the variable PERL_ROOT to what you find:
$ define/translation=concealed perl_root disk$dka100:[perl5_004_01.]
With:
$ perl -v
you should see something that looks like Figure 1.7:
VMSPerlVersion.PNG
Figure 1.7
Perl version for VMS
which tells you that you are on the right track.
When you have found Perl, you should have two pieces of information:
1) what version of Perl you have (in gory detail)
2) where Perl is installed.
We go over each point below.
When you say something like:
C:\>perl -v
The '-v' flag gets the version of Perl. The text that comes out of 'perl -v' is pretty much independent of the operating system that you are running on. The text that you get will look something like this:
This is perl, version 5.003 with EMBED
built under solaris at Sept 13 1997 16:06:39
+ suidperl security patch
Copyright 1987-1997, Larry Wall
Perl may be copied only under the terms of either the Artistic License or the
GNU General Public License, which may be found in the Perl 5.0 source kit.*
If you even want more gory details than this, you can say:
which will give you almost everything about how Perl is configured. |
which contains a lot of useful information. Some small points: the 'GNU' General Public License lets you modify and distribute the source code at will, in code or executable form, as long as you keep the notices of recognition in the code (I'm no lawyer, so see the file 'Artistic' in the standard distribution.)
The line '+suidperl security patch' (and lines like it) bear witness to some pretty traumatic bugs that were found and fixed. As of this writing, the only bug which qualifies to be this severe was the suidperl bug, which is gone in versions 5.003 and above.
It is important that this results in the version number. It should be 5.000 or higher, preferably 5.005. (Certain OS'es are not at version 5.005 - MacPerl is at 5.003 - but Perl's version should be 5.005 on any other operating system that we mention.)
The version number is especially important because of the changes that are made between even small versions. Perl has a pretty unique versioning system. In a Perl version tagged 5.001, that '1' in the thousandth place is almost as important as the '5'! Supposedly, this is to allow for versions 5.001 through 5.999, but seldom does it get this far. Version 4 lasted up to 4.036, taking over 3 years, and then there was a collective decision that making Perl object oriented warranted a '5.000'.
Even small releases of Perl are done with care (and really are not that small!) For example, perl5.004 to perl5.005 added:
1) Compiler Support ability to compile to Perlish bytecode (portable, machine-like code) or standard C.
2) Thread Support ability to make processes 'talk' together by sending messages back and forth.
3) UNIX to Windows 'code merge' Perl used to be split into two separate ports: the central distribution, and ActiveState's version. This used to be a pain for portability. There is now one, central distribution, and it is working wonders.
On a more pragmatic note, you probably want to make sure that the version installed is version 5.004 or higher, preferably version 5.005. This book assumes 5.005, but will work transparently for most issues (except the compiler in the last chapter) for version 5.004.
If you want, in somewhat gory detail, a list of the changes for any given revision of Perl, you can see the Changes file found in the standard distribution. Which brings us to exactly how do you get a standard distribution of Perl? The next sections describe the installation of Perl.
Let's suppose that you want the latest, greatest Perl. Or, you just want to learn a lot about your operating system. Here are some advantages of getting/using your own Perl:
1) You learn more by doing the installation. Perl has ten years of experience in figuring out how to install itself on different systems. The Perl installation script squiggles through your operating system, finding out such esoteric things as 'whether or not your integers are big-endian', which system calls your operating system supports, etc. Perl understands how to use the information it retrieves.
2)You can compile Perl with the options you choose. We give some of the more helpful ways to compile Perl. The debugging switch, for example, lets you see the guts of how Perl is doing things.
3) You can add modules very easily. Perl has a special place called CPAN (stands for Comprehensive Perl Archive Network), which contains lots of user contributed modules. These are pieces of code that people have built to do anything from date parsing to database connection.
4) You can avoid network problems. If you are using centrally installed Perl from '/usr/local/bin', or 'E:\perl>', then you are using Perl over a network (LAN or Network File System). This makes you vulnerable to having that network go down. Hence, if you are to use Perl for mission critical applications, you definitely want to get a secure copy.
5) You can make a 'self contained' package. Some people package the Perl executable that they build with the source code that they write. That way, if they need to sell this code, or move it to a different system, there is a self-contained package.
Here are the disadvantages of compiling your own Perl:
1) You need a C compiler to make your own Perl. For example, the UNIX variant Solaris doesn't come bundled with a C compiler, so you need to get your own or buy theirs. This drawback is somewhat offset by ActiveState, which has a packaged Windows 95, Windows NT binary.
2) Compiling it yourself is more work. Once compiled, you need to maintain Perl yourself. Since you are building it yourself, you are responsible for making sure that it works. This may be unacceptable.
3) A little more knowledge is required for installation. This is true if you are not using a pre-compiled version. You need to understand the compile steps and how to execute them.
4) If you are not careful, everybody will be installing their own Perl. At one extreme, you can have one centralized Perl. This may be too restrictive. On the other end, you have a Perl for each user (which may bring the storage capacity of the system to its knees!) Therefore, if you install your own executable, you need to gauge the lack of flexibility vs. the amount of maintenance you need to do. Your system administrator may be able to help with this too.
Given these advantages and disadvantages, I still say that it is a good thing for any UNIX user to install their own Perl, even if they delete it after they are finished with the installation. Installation of Perl is a good learning experience on any OS.
Therefore, below are the steps to compile and install a new Perl binary. Just go to the correct OS, and follow the steps.
The only option for installing Perl on a UNIX box is to get the source code and install it yourself. If you are lucky, you can get a binary version for your UNIX operating system, but you are actually probably better off building it yourself.
There are three steps to installing Perl on a UNIX system:
1) Get the source code. Go to one of the Comprehensive Perl Archive Network (CPAN) sites and get it via ftp.
2) Configure Perl to be installed on your particular machine Customize Perl for your particular configuation.
3) make, test, and install Perl on your machine. This is usually the easiest steps because Perl gets the installation correct almost 100% of the time.
If you are impatient and want to get going right away, here is a (pretty much) verbatim list of what you are going to type:
prompt% cd <temporary_directory>
prompt%ftp ftp.cs.colorado.com (or ftp.cs.colorado.edu,
or any of the sites mentioned
here after you log in.)
(login as anonymous, password email address)
ftp> cd /pub/perl/CPAN/src
ftp> get latest.tar.gz
ftp> exit
prompt% gunzip latest.tar.gz
prompt% tar xvf latest.tar.gz
prompt% cd perl5.004 (or whatever version is
installed)
prompt% sh configure --prefix='/where/you/want/perl/installed'
prompt% make ( makes perl into a local executable
prompt% make test ( test Perl to see if it built correctly.)
prompt% make install ( installs Perl into the correct place )
In fact, all of the steps, apart from the ftp step are automatic, and that too would be automatic if you had had Perl installed in the first place. This is a catch-22. You could script this if you had Perl, but you would not need to run the script if you had Perl in the first place!
Usually when I am consulting, I write a small shell script that does everything listed above for me given an argument, such as the release number. I then do the ftp manually.
We go into each of the above steps in more detail below.
The first thing you need to do to install Perl is to get the source code, and, if you do not have one already, a C compiler. If you don't have a compiler, then there are two choices:
1) get gcc, which is the standard default compiler
2) buy a C compiler
Of course (isn't it always the case) you need to compile the gcc compiler, so step one is not the easiest. If your system does not have it installed, you are going to have to find a binary. Usually the best place to get a binary is by talking to a newsgroup associated with the OS (comp.unix.solaris, for example).
Alternatively, you might ask for a Perl binary from comp.lang.perl.misc. As far as I know, there are very few standard Perl binaries for UNIX, since there are as many flavors of UNIX as there are pebbles on a beach.
Anyway, assuming that you have a Perl compiler, you can get the latest source code from any one of the CPAN sites. CPAN, again, stands for Comprehensive Perl Archive Network, and we shall see quite a bit of CPAN in this book. Table 1.1 gives a list of some of the more important CPAN sites, along with their traffic levels:
Table 1.1 CPAN sites
ftp.funet.fi/pub/languages/perl/CPAN medium (Finland)
uiarchive.uiuc.edu/pub/lang/perl/CPAN moderately heavy (fast link)
ftp.cs.colorado.edu/pub/perl/CPAN relatively light
ftp.cdrom.com/pub/perl/CPAN medium (fast link)
ftp.digital.com/pub/plan/perl/CPAN moderately heavy (fast link)
ftp.perl.com/pub/perl/CPAN heavy and slow (perl home page)
ftp.demon.co.uk/pub/perl/CPAN medium (UK)
ftp.sai.msu.su/pub/lang/perl/CPAN Unknown (moscow)
ftp.cs.ruu.nl/pub/PERL/CPAN Unknown (netherlands)
ftp.uni-hamburg.de/pub/soft/lang/perl/CPAN medium (germany)
There are many more (95 in total) but this is a good sampling. To download them you can simply say:
prompt%ftp ftp.cs.colorado.edu (or ftp.demon.co.uk
or any of the sites mentioned
here after you log in.)
(login as anonymous, password email address)
ftp> cd /pub/perl/CPAN/src
ftp> get latest.tar.gz
ftp> exit
prompt% gunzip latest.tar.gz
prompt% tar xvf latest.tar.gz
Or, if you are a browser fan, simply point your browser to http://www.perl.com/perl/info/software.html, and look where it says:
Just click to download the latest Perl source (currently Perl version 5.004_01) from a fast link. This version is a stable, production release (not beta) that compiles out of the box for virtually all flavors of UNIX (its native environment), plus VMS, OS/2, and 32-bit Windows platforms as well. Check out its installation notes for details (or see the INSTALL file in the src directory.) Read the beta release notes and/or documentation.
If you click on 'latest Perl source', this will do exactly the same thing, probably even better than the ftp because it is platform independent.
After you have gotten the Perl source, then type:
prompt% gunzip latest.tar.gz;
prompt% tar xvf latest.tar
to unpack the software. If gunzip is not on your system, you are going to need to go to ftp.gnu.ai.mit.edu. Go into the directory that is created by tar and it looks something like Figure 1.8:
Distribute.PNG
Figure 1.8
Perl distribution directory
Some important files to read right away:
README: the readme file for various UNIX OS'es.
INSTALL: More information on installation for UNIX
Artistic: Information on what the whole 'Free Software' concept is about. This should satisfy most lawyers that you can in fact use Perl for free.
You can proceed to the next step after you have skimmed through each of these files.
The second thing to do in compiling Perl is to configure it so Perl knows on which system it is being installed. You have two choices:
1) Configure Perl 5 interactively, which is particularly helpful for those of you just starting out with Perl.
2) Configure Perl 5 non-interactively using system defaults.
Both of these use Perl's Artificial Intelligence program called Configure to figure out your system. Yes, it is Artificial Intelligence, there is no other way to describe it.
Configure is the script which is created by metaconfig, another program written by Larry Wall. It goes through your system to diagnose exactly how Perl is going to be created. As I said, there are as many different types of UNIXes as there are angels on the head of a pin, and it is Configure's job to fine tune how Perl will build on your particular brand.
If you wish to configure Perl interactively, and give yourself the chance to see what is going on, type:
prompt% sh Configure
in the directory where you put the Perl distribution. Then answer questions such as what operating system you use, which version of rm you use, etc. Perl is almost 100% accurate in these cases, but it can be fooled by particularly strange variants of UNIX.
By typing:
prompt% sh Configure
you give yourself the chance to override what Perl thinks it already knows. At each step where Configure needs a value, it will prompt you for a value. Press return to accept the default, or type what you want to change.
A sample of the output given by the Configure script is given in Figure 1.9:
Configure.PNG
Figure 1.9
entitled 'configure script output'
As I said, do not worry about the questions that are there. Simply be aware of what is going on, and see the defaults. After the questions are over, you are ready to make Perl.
You probably answered about 100 questions if you have gone through the Perl configuration process interactively. Most likely, you accepted the default for pretty much every question, since Perl already knew the answer! And if you did have to enter something different, it was the exception and not the rule.
You can use a different configure script, this one to build things automatically. This configure script is called configure (lower case), and it does basically the same thing as Configure (upper case) but does it automatically. Simply type:
prompt% sh configure (plus command switches here)
Now, Perl will let you sit back and watch it build without user input.
This second form of configuring Perl is especially helpful if you want to have several versions of Perl around. By putting extra command switches on after 'sh configure', you are giving Perl directives on how to build. You can do the same thing with the interactive Configure, but that is much more prone to error since you are answering hundreds of questions, and may mistype an answer, or miss a question altogether. Here is an example of using switches with configure. Let's say you want to install your own personal copy of Perl in your home directory. Type:
sh configure --prefix=~/perl --html=~/perl/html
Now when you install Perl, it will install in your home directory, under $HOME/perl, and install the html-ified documentation in $HOME/perl/html
Or, if you want to compile Perl with the debugging flag turned on (this is great for actually seeing how Perl works) type:
prompt% sh configure -D ccflags='-DDEBUGGING'
to turn on the debugging switch.
Another option is to use gcc, the gnu compiler instead of cc, default installed compiler, by using:
prompt% sh configure -D'cc=gcc'
There are many of these installation options. However, they are scantily documented. These are the three most used ones. For the full set of options, see the file config.sh which is produced by the build process.
You are now ready to actually build Perl. When Configure is finished, it says 'Now you must run a make'. Type:
prompt% make
and watch it go. After this is complete, type:
prompt% make test
to see Perl test itself to make sure all its functionality is there.
Finally, if you are installing your own version of Perl or you are the system administrator and want to install it a centralized directory, type:
prompt% make install
This copies all of the binaries, libraries, etc. that come along with Perl, into the place where you specified your 'prefix' (i.e.: sh configure --prefix=/my/directory/please will install into /my/directory/please.)
After you are finished installing, test your version of Perl in a more informal way. First, put Perl in your path:
prompt% PATH=$PATH:/my/directory/please;
with ksh, or
prompt% setenv PATH "$PATH:/my/directory/path"
with tcsh. You should, after this script is done, be able to say something like what is shown in Figure 1.10:
UnixTest.PNG
Figure 1.10
UNIX Testing Shell
If Perl is installed correctly, it should bounce back the statement for you.
Perl almost always gets it right installing onto your UNIX box, but not always. Troubleshooting is a complicated art, of course, but there are three basic things that you can do which will point out (or correct) about 80% of the errors encountered during an installation:
1) Remove config.sh and then install again.
When Perl gets installed by the configure script above, it creates a config.sh file which contains all of the information found about your system.
However, and this is important, config.sh does not go away the next time you build Perl. You will have to remove this file if you want to install it on a different OS. Say you are working on an older platform of SunOS, and then the platform gets upgraded. Chances are, your config.sh just became obsolete, and when you try to install it again, BOOM. Therefore, make sure that you remove it before installing again.
2) Try installing on a machine with the same OS.
Perl depends on a lot of components on your OS, and they have bugs from time to time, or are mis-installed. If Perl installs correctly on the 'other' machine, you know it is a problem with one of the underlying components (which you can see by the Perl install steps)
3) Try replacing component by component.
Replacing component by component will get perhaps 70% of the problems out there. This is a good, brute force method in case that everything fails and you need to get Perl installed in a hurry.
Finally, there are the resources listed at the end of the chapter which may help tremendously. When everything else fails, contact other people to get help. After all, you might have even found a bug in Perl itself!
You can do two basic things if you want to use Perl on a UNIX box. You can either check to see if UNIX is there, or you can build it yourself. Both have plusses and minuses: building Perl yourself means more hassle yet more flexible, while using an installed version means less flexible, yet less work.
Deciding which one you wish to do depends on the relative importance of flexibility in your using Perl. If you want more flexibility, install it yourself. Otherwise, use the system's pre-built Perl. Just don't forget to check if the pre-installed Perl is a 'good' Perl or not (i.e.: above version 5.003).
Unlike the build on UNIX, you have two alternatives to build on Windows NT and Windows 95. You can install a binary that comes directly out of the box, or you can compile it using Visual C++ or Borland C++.
But first, we need to talk about an issue that is still hanging about the Perl community, and which still is the cause for a great deal of confusion. That issue is the recent merger of two separate Perl ports that were developed by different groups. This is discussed below.
Until recently, Perl on Windows NT and Windows 95 consisted of two separate ports, which unfortunately, were incompatible. These two ports were both developed to work on windows platforms, and each port was supported by a separate group. These ports were:
1) the standard distribution version of Perl.
2) the ActiveState version of Perl.
The standard distribution was the Perl that we talked about above. It is available for almost any OS under the sun, and was maintained by the central 'perl5 porters' group. The ActiveState version of Perl sprung from the company ActiveState. They were a company funded by Microsoft to create a fully Win32-aware Perl.
The ActiveState version of Perl had a lot of the Windows-specific functionality, such items as interfaces into OLE (or ActiveX), ODBC, the Registry, and what not. Table 1.2 lists them in no particular order:
Table 1.2 - Windows Modules
Win32::ChangeNotify Allows you to monitor 'when' a file or directory changes.
Win32::EventLog Allows you to monitor the NT event log (NT only)
Win32::File Sets attributes in a file for windows NT
Win32::FileSecurity Sets permissions for windows NT files
Win32::Mutex Allows for 'Mutually shared objects', ie: so you can synchronize more than one process together
Win32::Semaphore: Makes a Semaphore object (lets you control flow
between multiple processes. An extension of the Mutex
Win32::NetAdmin: Manages users and groups in WinNT (only works on NT)
Win32::NetResource: Manages resources (printers, disks, etc) over a network.
Win32::Process: Execute a Windows process inside Windows95/NT
Win32::Registry: Gives access to the Registry.
Win32::Service: Allows you to start services on a given computer.(ftp, etc)
Win32::WinError: Allows you to handle windows errors automatically.
OLE Allows for you to use object linking and imbedding
ODBC Allows you to connect to an ODBC style database.
NOT included in the internal distribution, but available, and on the accompanying diskette.
As any Windows programmer knows, having these types of modules is absolutely essential to windows programming, especially OLE. However, ActiveState had some problems. It was not usable with the vast number of UNIX modules out there, wasn't easily extendable (writing C or C++ extensions was a black art in ActiveState's Perl) and had some syntactical differences with regular Perl.
On the other hand, the standard distribution of Perl was stable, extendable, widely used, developing at a rapid pace, and was running rampant in popularity. But it did not have those essential Windows modules which allow for true windows programming.
It was natural that the two version of Perl should merge, and that merge has already proved a great success. Having the same source code to implement the Perl language on both platforms (rather than simply a specification that companies can follow and break at will as in the case of C++ and Java) has made for very smooth experience in porting from NT to UNIX and vice versa.*
*
*
There are some headaches of course, due to the way that the UNIX and NT operating systems differ, but those differences are summarized very neatly inside the README files that come along with the distribution. * |
This merge happened relatively recently, however, and the one practical thing that you should take out of this discussion is do not use any binary from ActiveState before version 5.005. If you have a binary prior to 5.005, you are going to want to re-install this binary over the one you have. This means that you will want to:
1) check the version of your Perl executable
2) install the newest Perl, just to be on the safe side
There are two different ways of installing a new Perl executable: by getting an 'already built' binary, and by installing it yourself.
To install a self-extracting binary on Windows 95 or NT:
1) Obtain the latest binary version of Perl5 which is available on http://www.ActiveState.com, or on the disk that comes along with this book. (you can also pick up binary distributions as well which give more than just the 'bare bones' of Perl. They also provide huge numbers of modules, so go to that site for more information.) This is self-extracting archive, so all you have to do is copy it to a folder. If you see the box in figure 1.11, you know you are fine:
BinActiveState.PNS
Figure 1.11
caption 'inputting install location to Perl'
2) In Windows 95, click on the file that you have just downloaded. The self extracting archive that you have just downloaded executes a DOS shell, and brings up the following notice (in Figure 1.12):
WinInstallQues.PNS
Figure 1.12
caption 'asking if you want to install Perl'
<insert screen for Perl installation here Figure 1.12 is 'prompt for windows install'>
3) type 'y' at the question 'Are you sure you want to install?'
This automatically transfers all of the files over to the directory C:\perl, in the proper places for Perl to use. All the defaults for where Perl is supposed to go are handled transparently, and you don't need to do a thing. Very convenient, and very quick.
The previous installation of Perl is not very flexible. For example, as of this writing, there is no way of changing the installation directory of Perl. So you are pretty much stuck with having your Perl executable in C:\perl.
As a result, you may find it very helpful to install Perl via a compiler. (This will also help you when you come to installing modules, below.) Perl5.005 will compile out of the box with both Visual C++ and the Borland C++ compiler.
Getting the NT source code is, well, exactly the same as getting the UNIX Source code. After all the code itself is the same!
However, there are two main mirrors which you may want to check out for getting the Perl source code. You can get it from ActiveState, (http://www.ActiveState.com) or from the Perl home page (http://www.perl.com/perl/info/software.html) The ActiveState page provides some Windows-specific information, and the Perl home page is very comprehensive, so you will want to check out both.
When you download the Perl source from one of these two sites, you are going to need to install it a bit differently than on UNIX. The source code comes with the '.tar.gz' extension, which (for those of you who aren't familiar with UNIX tools) is a 'tarred', 'gzipped' file, which you are going to need to uncompress and install. The easiest way to do this is to get the WinZip shareware package from http://www.winzip.com which handles quite a few different formats for you as zipped files, compressed files, and of course tarred files.
I've heard of a couple of problems with this for installing the popular UNIX editor emacs on NT, but never for Perl. If you are having problems with this, look at getting the freeware 'gunzip.exe' and 'tar.exe' from ftp://ftp.cs.washington.edu/pub/ntemacs/latest/i386/utilities/i386 which are used like their UNIX counterparts (see up above). (If you are an emacs fan on the UNIX side, you might as well pick this up, too.)
Note that while you are uncompressing Perl, you will get a 'non-existant' or 'false' error. There are two files in the Perl distribution - Configure and configure - which look the same to NT because of the case-insensitivity of NT. Just ignore this error. It was calculated as the best way to keep backwards compatibility with the UNIX Perl, which has probably millions of scripts with 'Configure' in it!
It is a little known fact, but both Borland and Visual C++ have a way to build projects outside their Graphical Interface. UNIX affiliates will recognize the tool: make.
Visual C++'s version of make is called 'nmake', and Borland's version is called 'dmake'. And since Perl came from a UNIX (command line driven) background, it made sense that it used these familiar tools on NT and Windows 95. Below are the core steps for installing Perl using a Windows NT/95 compiler (the process we have chosen to detail is nmake with Visual C++).
Making a Perl executable with gcc is possible, but I have never tried it and can not guarantee that the executable produced can use any of the windows compilers. See the README.cygwin32 file that comes along with the standard distribution for more information.
Reading README.win32 is a prerequisite to a good, successful install. It is contained in the standard distribution, and has all the steps describe below, fleshed out in greater detail. As a benefit, it gives some helpful tips on troubleshooting. In particular, you need a 32 bit compiler (any compiler after version 2 for VC++ should be fine), and about 15 mb of disk space.
If you do not have a C++ compiler, and are not planning on doing GUI development with Visual C++, you can get the 'Learning Version' for about $400 dollars less. Since Perl doesn't have GUI calls inherent in it (although it can manipulate GUI's through OLE) it works just fine!
Step #1: Set up the compile environment.
First, get a cmd command tool. The cmd tool you want is found under the default drop down list box under 'Start', under 'Programs', and labeled 'Command Prompt'
Get a shell, and look for the 'vcvars32.bat' file that comes along with visual C++. Mine is under 'Program Files\DevStudio\VC\bin' so I would type:
c:\> C:\Program Files\DevStudio\VC\bin\vcvars32
which is the file that sets up a command line programming environment, and comes with the Visual C++ distribution.
This bat file contains all the environmental variables that makes nmake work. (nmake is the tool that you will use to build Perl on the command line) Go to Step #2.
Step #2: Edit the Makefile inside the win32 directory
The Makefile that creates Perl on Windows machines should pretty much work straight out of the box. It is located in the win32 subdirectory under the standard distribution. Simply go into that directory:
C:\> cd <perl_install_directory>\win32
where <perl_install_directory> is the directory which contains the unpacked the Perl distribution ('perl5.005' for example). Take a look at the file 'Makefile', as this contains the instructions that VC++ will use to build Perl for you.
Even though the makefile is fairly straightforward, there are a couple of things that you can customize here. You should really look it over before you flip the switch and start compiling:
1) the variable INST_DRV controls on which drive Perl is to be installed. The default is C:
2) the variable INST_TOP controls in which directory Perl is to be installed. Right now, the default is to have Perl installed in the directory '\perl'.
3) if you want to make a debug version of Perl, un-comment the line saying 'CFG=debug'. We shall use the debug version of Perl later to debug regular expressions, and other such things.
You are probably going to want to make both types of Perl, regular and debugging, and store them as different names. For instance, you might want to make a regular version of Perl, and install it as 'Perl', and make a debug version of Perl and call it 'perldebug'.
Step #3: Compile, test, and install
Now, you are ready to actually go ahead and compile Perl. Simply make sure that you are in the win32 directory by saying:
C:\> cd <perl_install_version>\win32
where <perl_install_version> is, again, the place where you unpacked Perl. Now say:
C:\> nmake
which should display something like you see in Figure 1.13:
NTmake.PNS
Figure 1.13
Making Perl with NT
This actually creates a Perl executable. You now need to test it, to make sure that the Perl executable is OK:
C:\> nmake test
which should display the following, in Figure 1.14 when finished:
NTtest.PNS
Figure 1.14
Testing Perl on NT.
Note that several tests will be 'skipped on this platform'. This indicates that Perl cannot do the certain function on NT because it is not supported/irrelevant for the operating system.*
This will not be much of a problem if you are writing scripts for both UNIX and NT because Perl warns you loud and clear if you try to call a function that isn't supported on NT. The main thing you are going to have to look out for if you are a UNIX programmer is the fork() system call. It doesn't work on NT, whereas it is pretty common on UNIX. |
Given that you see a 'All tests successful', you should now say:
C:\> nmake install
which will install Perl into wherever you set INST_TOP. Add onto your path the place where the Perl binary was installed, with a statement like:
C:\> set path = C:\perl\bin;"%PATH%";
and do a preliminary test, something like Figure 1.15:
NTweasel.fig
Figure 1.15
Testing the new executable
and bingo, you are ready to use Perl.
Perl is easier to install onto NT or Windows 95 than UNIX in many ways. After all, there are only two operating systems that need to be supported, and if Perl works on one, then it will work on them all. At least that is the theory. Although problems with Perl are rare on NT, when problems do arise, they are often very difficult to detect and eliminate. This is due to the central way that NT and Win95 do its administration.
NT and Win95 have a centralized, 'black box' (meaning you cannot look at it easily) called the Registry, where installed programs register themselves to make the installation as seamless as possible. Unfortunately, if a program decides to install a certain driver that makes another program break, well, that's the other program's problem. By extension, this is also your problem.
Perl bypasses the registry, avoiding much of the above problems, but if you are dealing with modules that use other resources on your machine (ODBC, OLE, etc.) you may run into difficulty. What to do? Well, there are quite a few things you can do to get out of these difficulties:
1) install a binary version and see if the problem goes away. For whatever reason, you may have compiled Perl incorrectly. Or your compiler was faulty (I have heard of a couple of cases in which VC++ 4.2 thought it was version 5.0, which caused problems.) If the problem goes away after installing the binary, you know at least where to look the next time you install.
2) reinstall your C++ compiler. If #1 is the case, you probably have installed your C++ compiler wrong. Reinstall your compiler, and rebuild Perl and see if the problem goes away.
3) Use a 'registry doctor' There are several products devoted to the problems that can occur with both Windows 95 and Windows NT versions of the registry. Check out Norton Disk Doctor as one of the best products to deal with problems.
Note that this line is mainly meant for corporate technical support, but we don't mind helping out. Please don't abuse this!! |
As I said, however, installation and usage bugs are fairly rare on NT. You should get by with no problem.
You have two ways to build Perl on NT: by installing a pre-built version and by compiling it yourself.
Using the pre-built Perl can get you up and going right away, but you are pretty much confined to installing it into one place. If you want to use the extra modules that people have written for Perl, you are dependent on the people who write these modules making a binary form and putting it out on CPAN.
Building Perl yourself can be a fun trip and gives you a lot more functionality, but it does require a Windows-aware C++ compiler. The best option in this case would be to get the 'learning' C++ compiler from Microsoft, as long as you are not too concerned about writing Windows programs. It costs $78 the last time I checked, and contains a completely functional 32 bit compiler that will work for everything in installing Perl.
Building Perl on the Macintosh is done exclusively through a self-installing archive. You are going to need to:
1) get the correct, compacted distribution
2) unpack that distribution
After that, run and enjoy! Of all the operating systems listed here, Perl on the Macintosh is the easiest to install. Short and sweet, let's go through the two steps listed here. First though, you are going to need a unpacker utility to help with the files.
The distribution listed below is in Mac BinaryII format. Although you could get many different types of utility to uncompress this format, Stuffit Expander is the best. It is available at http://www.aladdinsys.com as shareware, and if you don't have it now, you are probably going to want to get it. Simply follow the site from the home page, download it, and double click on the 'stuffit expander' file. Then go onto the next step.
You are going to need to go to CPAN to download the Macintosh distribution. Go to the central Perl site at http://www.perl.com/perl/info/software.html and from there use the 'CPAN multiplexer' as explained above in the 'install UNIX' session, or directly go to one of the CPAN sites themselves, as listed in Table 1.1. MacPerl is sitting under the 'ports/mac' directory in CPAN; hence you could go to the site ftp://ftp.cs.colorado.edu/pub/perl/CPAN/ports/mac and directly download it from there.
Now, there is one important thing that you need to know about MacPerl. As stated above, there are two separate distributions for the Mac. One is in a file which will have the following format: ftp://ftp.cs.colorado.edu/pub/perl/CPAN/ports/mac/Mac_Perl_513r2_tool.bin.
Here, the 513r2 is a version, and the 'tool' designation is what you are looking for. Another is a file with the format: ftp://ftp.cs.colorado.edu/pub/perl/CPAN/ports/mac/Mac_Perl_513r2_appl.bin.
Unless you have CodeWarrior (and thus the package MPW) from http://www.metrowerks.com, you are going to want to get the appl.bin version of the file. The tool.bin file will come out as garbage on your Mac, with no icons at all. This version is for CodeWarrior; read the MacPerlFAQ.txt file that is in the same directory.
Just a warning that there will in all likelihood be a false error reported: "Mac BinaryII will be used to inflate the file." Ignore it, and assuming 'Stuffit Expander' is installed, double-click on the file that you have downloaded (*appl.bin). This expands it into a 'Stuffit Expander' archive (this is subject to change next release, so Matthias - the person who did the MacPerl port - tells me.)
Anyway, once you have unstuffed the MacPerl file you downloaded and double-clicked on it, you should get the following screen:
MacInstall.PNS
Figure 1.16
Mac Installation prompt
Just tell Perl where you want to install it, and voila! you can use your new binary.
The binary is called 'MacPerl' (it is the one with the Camel and the pyramid, what else!), and double clicking starts it. Figure 1.17 and 1.18 give a little bit more on how the MacPerl application works. Figure 1.19 shows where you actually will be running your scripts.
MacRunScript.PNS
Figure 1.17
Running a Mac Perl script
Under the 'Scripts' menu item there are two main ways that you run Perl. At the bottom there is a 'one liner' where you can type any Perl command you want. The second way is through loading a file. Both ways have their uses.
Figure 1.X shows the other main thing that you need to know; how to customize your environment:
MacCustomize.PNS
Figure 1.18
Customizing your Macintosh Perl environment
This menu is found under 'Edit:Preferences', and this is where you will tell Perl where all your libraries are, how you want to edit your scripts and so forth.
To test out your new install, simply say something like what you see in Figure 1.X, in the 'one liner' section under 'scripts':
MacTest.PNS
Figure 1.19
Testing MacPerl
There are other ways of running the Macintosh Perl application. If you are interested, take a look at the mac.pod file that comes with the Macintosh distribution. See the section on documentation below for more detail.
Building Perl on OS/2 is a bit more complicated than building on other platforms, because you need to get other software (besides such simple things as decompression software) and install that before touching the OS/2 distribution. Below is a quick summary of what you need, along with a common install path.
For more information on this read the 'README.os2' file that comes along with the documentation. Please! There are a lot of options for installing onto OS/2 and you should take a look at them closely.
You can also build Perl on MS-DOS, Win3.1, Win95, and NT if you want to this way, and we will briefly talk about this.* If you are on Win95 and WinNT you are probably better off using the 'native' way of building Perl as described above.
The way that I suggest installing perl on Win95 or Windows NT is going with the standard distribution. The way that I suggest installing perl on MS-DOS systems is with a very decent DOS Perl port called DJGPP available on CPAN. |
You are going to need a couple of things before you install your OS/2 executable. First, you are going to need a package called EMX, or RSX. EMX is available in ftp://ftp.cdrom.com/pub/os2/emx09c/emxrt.zip and RSX is available in ftp://ftp.leo.org/pub/comp/os/os2/leo/devtools/emx+gcc/contrib/rsx*.zip. EMX and RSX act as a DOS extender, which means that you can compile Perl this way on other platforms as well as OS/2. (You can get a working version of Perl on Win-NT, Win-95, Win-31, even MS-DOS without windows!)
What's the difference?
RSX needs a server called DPMI running on your system; this provides subroutines on MS-DOS, Win-31, etc. that approach the multi-tasking that other Oses pretty much take for granted. (DPMI - for those of you uninitiated in MS-DOSish - stands for DOS Protected Mode Interface, and is available on the Win* platforms.)
EMX works on an older version of DPMI called VCPI for 'Virtual Control Program Interface'. Unfortunately, VCPI and DPMI are not compatible, so EMX won't work on DPMI, and RSX will not work on VCPI!
Table 1.3 provides the Operating System cross reference that you will need to get up and running:
Table 1.3 - RSX and EMX, which?
File Operating System
ftp://ftp.cdrom.com/pub/os2/emx09c/emxrt.zip OS/2
MS-DOS
ftp://ftp.leo.org/pub/comp/os/os2/leo/devtools/emx+gcc/contrib/rsx510.zip Win3.1
Win95
ftp://ftp.leo.org/pub/comp/os/os2/leo/devtools/emx+gcc/contrib/rsxnt131.zip NT 3.51 or above
If you are on DOS, get EMX. If you are anywhere else, get RSX. And if you are paranoid, get both. The two packages are smart enough to figure out which one is supposed to run. And, while you are there, you might as well pick up the gnu development tools. Yes, you can build gcc, Perl, even emacs on a DOS box; if you are so inclined, you can get a UNIX-like environment, too, with bash. Follow the instructions in the distributions on how to do this.
Once you have got either EMX or RSX, you are going to have to configure Config.SYS to automatically run when you start your computer. Then Reboot and go to the next step.
You can get the regular distribution and also get the gcc tools to compile Perl, but there is also an automatic install process that you might want to check out. In any case, you need unzip.exe. It is available in several places. The best place to get it is http://www.cdrom.com/pub/infozip which is an exhaustive source for zip on more than 30 platforms.
Then, you can either download the source or you can get the zipped executables themselves. These are available on any CPAN site (see Table 1.3 above). This is one such, fully qualified path: ftp://ftp.cs.colorado.edu/mirrors/CPAN/authors/id/ILYAZ/os2/latest
There will be a slough of zip files in this directory: you need them all. They are listed below:
plinstl0.zip plINSTAL.zip plREADME.zip perl_utl.zip perl_ste.zip
perl_sh.zip perl_pod.zip perl_mlb.zip perl_man.zip perl_mam.zip
perl_inf.zip perl_exc.zip perl_blb.zip perl_aou.zip
Put these all into one directory, and make sure that unzip.exe is in your path. We talk about the installation of OS/2 Perl below. If you are going to build Perl on any of the Microsoft platforms, you will need to follow the directions in the README.os2 file, they get quite complicated! You might want to check out the DJGPP port instead (instructions given below).
Now, unzip plinst10.zip. This is the 'master control' switch for installing Perl on OS/2. To flip this master control switch, type:
[H:] install.exe
and away you go! The first thing you should see is something like Figure 1.20:
OSCamel1.PNS
Figure 1.20
Install Screen
This is the Perl Camel, the trademark of all pretty much all Perl-dom.*
*
It also so happens to be on the cover of Programming Perl by Larry Wall and Associates and is trademarked by O'Reilly and Associates. |
If you see this, you are on the right track. Read the instructions that come up next, and continue.
The next milestone looks something like this:
OSDirinstall1.PNG
Figure 1.21
Install components.
Each directory corresponds to a separate component of Perl that you may or may not choose to install. Go ahead and install them all, after clicking on the descriptions button to familiarize yourself with what is available. Finaly, a progress screen will come up, telling how close you are to done. When you are done, you should be able to do the test shown in figure 1.22:
OSMethinks1.PNG
Figure 1.22
Testing OS/2
If Perl echoes back the statement, you know that you are done.
The next operating system we will deal with is VMS. VMS's installation is very much like that of UNIX and NT's, but the syntax differs quite a bit.
You are going to need these prerequisite programs to install perl on VMS:
1) gunzip
2) tar
3) a C-compiler
4) MMS (DEC's make analog), or the freeware equivalent MMK
There are no surprises here. Uncompress the Perl source code, un-archive it, and then compile it into an executable using a make-like product. Chances are you already have these programs. If you type
$ gunzip --help
$ tar
$ gcc –version OR $ cc/version nl OR $ cc/list=file.lis nl:
$ mmk/ident OR mms/ident
and any of these items comes up blank, you are going to need to get them, install them, and put them in your path before going forward.
Every one of the programs outlined above (except MMK) has source code which resides at ftp://ftp.gnu.ai.mit.edu/pub/gnu, and, being a gnu archive site, this is mirrored quite a few places. Note that you cannot use gmake here because VMS uses conditional compilation. It lets you define certain steps inside the make process to be dependent on flags that you give to it on the command line.
If you are interested in getting pre-built binaries instead (you pretty much have no choice for MMK) you can go to the VMS binary site at ftp://ftp.digital.com/pub/VMS or ftp://ftp.wku.edu/vms/fileserv which has a good deal of compiled images that you can look at. MMK is found at ftp://ftp.wku.edu/madgoat/. GCC (the standalone compiler) can be found at ftp://ftp.cco.caltech.edu/pub/rankin/. In each case, when you get these programs, you can make an alias by saying:
$ tar == "$mydev:[mydir]vmstar-vax.exe"
where $mydev indicates to the shell (CLI) that the file is a binary, rather than a script (which is indicated by '@'). mydir is the physical directory where you have stored the compiled binaries.
You are now ready to compile Perl. VMS has been integrated into Perl's core source code, so you can compile right out of the box. Get the standard Perl distribution, by going to http://www.perl.com/perl/info.html and clicking on 'grab the latest source'. This will automatically transfer you over to a random fast link to get Perl.
Note that VMS has a limitation here; you can only have one '.' in any given filename. Hence, you may have to do a little name juggling to convert latest.tar.gz to latest.tar-gz; most ftp clients make this easy.
The installation of VMS is all command line driven. The first two steps are pretty vanilla:
$ gunzip latest.tar-gz
$ tar -xvf latest.tar
although you are probably going to want to do this where you can have lots of deep directories (as DISK$DEVICE:[000000]). When you untar the 'latest.tar' file in step #2, all the files will go to a default directory; namely '[.perl<version>]' (where version is the version of Perl, like [.perl5_004]).
Then change into that directory:
$ set default [.perl<version> ]
and look at the two major files that hold all of the information that you need in order to build Perl:
$ type/page README.vms
$ type/page [.vms]descrip.mms
The first file has copious amounts of information about how to build Perl on VMS. There are quite a few ways of doing it. The simplest way is to use MMS (DEC's formal project builder) or MMK (which is the make clone listed above.) As of now, there is no 'Configure' product available (as there is for UNIX) and since many different types of VMS exist out there, you are going to need to look at the file (config.vms) and provide the right defaults when you actually compile Perl.
(Side note: Once it comes into being, the command:
$ @[.vms]Configure "-des"
will do the tedious part of recognizing what configuration you are on, and automatically do this for you. By the time this book is published, it should be in existence.)
Then, find out which C compiler you are using by probing the version again:
$ cc/version nl:
DEC C V5.3-006 on OpenVMS Alpha V7.1
or if that does not work:
$ cc/list=file.lis nl:
or:
$ gcc --version
Cross-referencing the response you get from these commands with the [.vms]descrip.mms file, you can then choose the correct qualifiers for the mms executable (or mmk) to tell which Perl you are building:
$ mms/descrip=[.vms] /macro=("decc=1","__AXP__=1")
$ mms/descrip=[.vms] /macro=("decc=1","__AXP__=1") test
$ define/translation=concealed perl_root disk$dka200:[perl5_004_01.]
$ mms/descrip=[.vms] /macro=("decc=1","__AXP__=1") install
Steps #1, #2, #4 correspond to the 'make', 'make test', and 'make install' commands on other OS'es; this particular command builds Perl on an AXP machine with DEC's C compiler as the default.*
The 'define/... perl_root' command tells mms where it is going to install Perl; this should be another directory that has lots of deep directories. |
Now, to test your new Perl application, you can say:
VMSWhale.PNS
Figure 1.23
Testing the VMS application
which is the simplest one line script you can do (well 'perl -e 1;' is shorter, but not as interesting...)
The last OS we will consider installing Perl on is MS-DOS. Now, MS-DOS may not be the most glorious of systems, but it sure is the most widespread, and the ability to turn a 386 PC into a workstation without having to switch OS'es is a powerful incentive for lots of businesses out there to use Perl. Instead of switching OS'es, they can use Perl to do the difficult jobs that MS-DOS simply cannot do.
Believe it or not, but the OS running on 85% of all IBM PC's out there is (you guessed it) MS-DOS with Win3.1. Sometimes it isn't even that, it's just MS-DOS. As such they make great, cheap machines for web-servers or thin clients which can get information from other sources, collate mail, whatever. MS-DOS machines tend to end up running the menial tasks that all the other machines in the office are too expensive to do. However, to do this magic of turning a 386 into a Perl machine, you are going to need a couple of things.
The MS-DOS Perl port is built off of an initiative by Delorie Software (and blessed by the Free Software Foundation) called DJGPP.*
Stands for DJ's Gnu Programming Platform or somesuch ( I don't think they have come up with a name for it yet), and is quite popular. The 3D game Quake was programmed with DJGPP tools. |
DJGPP's goal is to make a 32-bit programming platform available for DOS machines that are in reality could be either 32 bit or 16 bit and greater than a 386. It works because the 386 and above are 32 bit machines, even though DOS is not. Check out http://www.delorie.com/djgpp for more detail.
The djgpp port is totally standalone, so you need absolutely no extra files besides pkzip (http://www.pkzip.com). However, if you are a UNIX user, you might want to pick up the DJGPP version of bash, a UNIX shell at the DJGPP site:
ftp.simtel.net/pub/simtelnet/gnu/djgpp/bshXXXXb.zip*
In fact, you might want to pick up all of your favorite UNIX tools at the same time: compiler, awk sed, gawk, grep, sh-utils, textutils, fileutils, diffutils, make and findutils. But you need none of them. They make DOS workable if you are a UNIX user. |
You can install Perl either via its binary distribution, or by downloading the djgpp development platform plus associated tools and compiling it. We discuss only installing the binary here. Go to the central distribution under the directory 'djgpp' for more information on installing via compilation.
First you need to get the Perl binary by going to the CPAN site nearest you:
ftp://ftp.cs.colorado.edu/pub/perl/CPAN/ports/msdos/djgpp/perlxxx.zip
Then, you need to unzip the binary package perl54b.zip, preserving the directory structure. Make sure that you have created a directory before you do this! Say:
c:\djgpp> pkunzip -d perlxxx.zip
Be careful that you have the '-d' modifier, since otherwise Perl will come out in one, flat directory, and it won't work.
If you want to have Perl in a different directory besides the default 'C:\djgpp', you need to edit the file lib\perl5\Config.pm, and replace every 'c:/djgpp' with your path. Suppose you wanted to install Perl inside 'C:\perl'. You would say:
c:\perl> pkunzip -d perlxxx.zip
c:\perl> bin/perl -i~ -pe "s'c:/djgpp'C:/perl'i;" lib\perl\Config.pm
The second line is simply Perl-ese to actually do the substitution correctly. It goes through the file Config.pm and replaces all the text strings 'C:/djgpp' with 'C:/perl' and backs up a copy of the original in 'lib\perl\Config.pm~'.
Make your environment know where to find the Perl variable by editing autoexec.bat or typing at the DOS prompt:
c:\> set PATH = "%PATH%;C:\perl\bin\perl"
or wherever you wanted to install it, and do a quick test of your new Perl application:
MSDOSWhale.PNS
Figure 1.24
Testing the MS-DOS application
And you should be in business. The MS-DOS port is a very robust one. It is built in virtual memory, works with win95 or DOS, works with most standard UNIX Modules, and generally can make working on DOS a lot more fun than without it.
Let's now shift some gears. When you get Perl installed, you also get a whole bunch of predefined functionality in what are termed modules. The additional functionality in ActiveState's port (that handled NT) is all in modules, for example. Likewise, the standard distribution of Perl has lots of useful modules.
Modules are simply files which contain functions that are helpful to use, but don't make sense to be included with the Perl executable itself. They are extensions onto the language, a special form of library. For example, the standard distribution contains a module called Benchmark which is helpful at timing Perl code, or to see how fast it is on average. There are other modules like this.
While the standard distribution has a lot of functionality in the form of modules, one of the key principles that Perl 5 was founded on was that it needs to be easily extendable. People need to be able to program functions that others would want to use, and then make them freely accessible for all.
This is the purpose of the Comprehensive Perl Archive Network, or CPAN for short. The index for CPAN is located on http://mox.Perl.com/CPAN. Look there for more information. This is actually several sites in one. Just pick the one most convenient for you. These sites list all of the publicly available modules for Perl. As the saying goes , 'Don't reinvent the wheel!'. There are modules here which I have found very useful and I touch on in this book. Here's a screen shot, complete with URL, in Figure 1.25:
CPANpict.PNS
Figure 1.25
caption 'CPAN, and some of the modules it contains'
As you can see, there are quite a few things here, including database interfaces, World Wide Web interfaces (through CGI), text manipulation, to name a few.
There are two ways that you can install modules: the easy way and the difficult way. More descriptively, you can either directly install them, or use a module called CPAN, which is the way at least which I prefer to do things. We go over each below.
The default, old way to install a package on UNIX or NT was as follows. You first needed to download it, using ftp. Then you typed something like:
prompt% gunzip Module.tar.gz
prompt% tar xvf Module.tar
prompt% cd Module
prompt% perl5 Makefile.PL (this uses the Perl5 configuration information stored when you said 'sh configure')
prompt% make
prompt% make test
prompt% make install
This would automatically make the instructions on how to build the module ('perl Makefile.PL' makes this instruction set in a 'Makefile'), and would put the module in a place that you could use it.
To test if the install copied the files correctly, you should be able to say:
use Module;
at the top of a script to include that module, without needing to know where that module is installed. This way doesn't really have any advantages though Perl itself is the best tool I know of for automating things, and Andreas Koenig with his CPAN module made things a lot easier. Of course, you can also get modules from the CD that accompanies this book; this has certain benefits too. We shall cover both of these methods below.
There cannot be enough praise heaped on this gem of a module; I have heard it described as 'the best thing since indoor plumbing', and as 'making large scale Perl distributed development possible'.
It does, however, require two things:
1) a TCP/IP connection to the internet.
2) a C/C++ compiler if you are going to do any 'installing' (some of the modules out there have C components, and CPAN will choke if you don't have a compiler set up.)
At the time of this writing, even the second requirement might go away, as CPAN begins to support binary distributions. Then you just pick up the compiled, tarred version of a file and install it.
If you do not have a C++ compiler and you are on windows NT or Windows 95, Gurusamy Sarathy has put together a tar file of most of the commonly used modules on NT for the intel chipset. This is available on CPAN (where else) under 'ftp://ftp.cs.colorado.edu/pub/perl/CPAN/authors/id/GSAR/perl5.004*bindist04-bc*gz' (where the '*' indicates multiple files. It takes about 6MB for the unzipped modules, and about 24MB for the total install, and includes such favorite modules as TkPerl, libnet, libwww, libwin32, various date manipulation modules, and much more. This saved me a lot of time in putting together the CD for this book btw. Thanks, Sarathy. |
So what is CPAN? CPAN is a catalog of available modules, a road map if you will, of what Perl functionality there is out there in web land. But it is more than that. Not only does it allow you to look at what is out there, it lets you
1) update modules that you already have
2) install new modules
3) install 'bundles' of new modules
So how do you use CPAN? It comes with the central distribution, so simply type:
C:\> perl -MCPAN -eshell
This is to be read as 'invoke Perl, using the module CPAN, and then evaluate the function shell inside the module CPAN'. After you type this, you should get a prompt:
cpan shell -- CPAN exploration and modules installation (v1.27)
Readline support available (try ``install Bundle::CPAN'')
cpan>
Take its advice. Type:
cpan> install Bundle::CPAN
And watch it go! The things it installs are:
MD5 (a security module),
Data-Dumper (a debugging module),
Net::Telnet (a module for handling telnet)
libnet (a module for handling net protocols like ftp)
Term::ReadKey ( a module for handling command line manipulation.)
CPAN-WAIT (enhanced CPAN functionality)
CPAN (latest version)
You have just gotten and installed many of the things you need to do Web development. This is an example of the bundle concept: these are modules that work very well together. Next, you can say:
cpan> i /Bundle/
to see exactly what bundles are available. At the time of this writing, the most important bundles are:
Bundle::Apache (bundle for the Apache web server)
Bundle::CPAN (bundle for CPAN (see above)
Bundle::LWP (bundle for Web protocols)
Bundle::Tk (bundle for Tk programming)
Bundle::libnet (bundle for net protocols)
If you are going to do Web programming, you will probably want to get Bundle::LWP.
There are other tricks you can do. You can see which modules of yours are out of date by typing:
cpan> r
which gives you reinstall suggestions, and you can say:
cpan> i /Debug/
to get information about all modules that have to do with debugging.
The CPAN is the most useful thing for Perl I've seen in years (well.. maybe besides the compiler!) . In fact, the install program on the CD that comes with this book is a wrapper around CPAN. (Did I mention that CPAN was programmable too?) Why write new code when you can reuse old code that does exactly the same thing?
The CD that accompanies this book also has several of the most commonly used modules, including all of the modules for accessing the internet, doing CGI and Web-crawler programs, database access, and so on. The main Perl script used to install all of the modules on the CD is called cdinstall.p, and is available in the top level of the CD. No matter if you are on UNIX, or NT, type:
D:\> cdinstall.p
assuming in this instance that you are on NT, and your CD player has the drive letter 'd:'. cdinstall.p is a Perl script, and requires that Perl is installed and in your path, so install Perl if you have not already done so.
cdinstall.p is also a self-configuring Perl script, so it will ask you a bunch of questions the first time you use it. These questions are kept inside a file called cdinstall.pm, which is then stored, default, in 'C:\temp' (windows) and '$HOME/.perlccd/cdinstall.pm' (UNIX).
After you have configured cdinstall.pm, you can then proceed to install different modules from the CD. I have inherited much of the interface from CPAN, so the usage is basically the same, except that you will be installing from disk rather than from the internet. If you want, for example, to see exactly what you can install, say:
cdpan> i /./
which then will give you a list of modules on the CD which you can install, and:
cdpan> install libnet
which would then go and install the libraries for doing net access into your directory. But the question has to be asked: why use the CD when you could use the modules on CPAN? We briefly cover this below.
So why use the CD when you could use CPAN? Well, I think that there are some major benefits to the CD.
The CD is tested for stability. The versions of modules on the CD have been tested on quite a few platforms: Win NT, Win 95, linux, SunOS, HPUX. If any problems have been found, I have noted them on the README files that are located on the CD.
You don't need a compiler for Windows with the CD. There are quite a few cultural differences between the UNIX and Windows communities. One of them is that Windows likes 'instant install' types of packages, whereas UNIX likes to build it yourself. Hence, we have pre-built all of important modules here on Windows NT/95 for your perusal.
Of course, there are advantages for the modules on CPAN, too:
1) Modules on CPAN have known bugs fixed in them. By getting more up to date modules, you can get around bugs that are in older versions of the modules.
2) Modules on CPAN are more compatible with newer versions of Perl. Since developers tend to go with the latest and greatest, their modules usually track the latest versions of the Perl executable. Hence, in the transition from perl5.004 to perl5.005, some modules may add threading support for example.
3) You are much more in tune with the latest developments with CPAN. We can't stress enough that Perl is geared towards people making contributions to make everybody's life easier. When you see something cool and try it, you are doing everybody good.
If you like to be in on the latest developments with the Perl world, you are better off going to CPAN to get your modules (after perhaps getting started with the CD). CPAN is also in the process of providing binaries for the most commonly used modules, so the necessity of having a compiler to use CPAN may be gone by the time this book comes to print.
If you like stable versions of your Perl modules, without a lot of experimentation, the CD is probably for you.
The final step in getting familiar with the Perl environment is to be able to use the documentation. Since Perl is a very hands-on language, this is a very important step for your long-term viability as a Perl programmer. Perl provides a great deal of cool documentation, but it does you no good if you cannot get at it. Probably the most ubiquitous format nowadays is html, and Perl installs the documentation in html format when you install Perl itself.
On NT, this default directory is
C:\><perl_install_path>\html
and on UNIX, this directory is whatever you put at the command line:
prompt% sh configure --html=/net/mymachine/httpd/htdocs/perldocs
This path then, whatever it is, will be the place where all documents are stored in future. (When you install new modules, their documentation will be automatically stored there as well.)*
If you are using the auto configure ('sh configure') on UNIX, make sure that you have put the '-html' argument to configure on the command line. Perl has no way of knowing on UNIX where to install html, and hence, it will not install any html documentation, anywhere, if you don't do this. |
Make sure that the documentation is installed by simply pointing your browser to:
file:C:\Perl\html\perl.htm
The same file in the UNIX world is perl.html. You will know that it is working when you see something like this (in Figure 1.25), assuming you are on windows:
Document.PNG
Figure 1.25
caption 'Beginning perl documentation, windows style'
Now, browsers are nice, of course but sometimes you simply want a hard copy of all the things that you have installed. That is what we talk about next.
Unfortunately, the central distribution of Perl is a little bit short in this area. There is no simple, cross-platform way of printing out all of the Perl documentation. Of course, you can easily go from an html document to a printout. Simply go underneath the file menu in Netscape, for example, and say 'print'. From what I've heard, this actually produces some reasonably sharp printouts.
But this will only print out one such document. What would be handy is something that would simply take all the documentation that comes with Perl, and all the modules that you have installed, and then dump them into one big file for printout. Perl doesn't have this facility built into it; therefore, I wrote one.
The Perl script in question is called docify.p, and it exists inside the 'scripts' section of the CD. Usage is really simple:
D:\scripts> docify.p
or
prompt% docify.p
This will ask you a question on where you want the Perl documents dumped. Right now, all it does is dump out everything (central Perl documents, module documents, everything) into one postscript file. By default this file is perldoc.ps in your home directory (on UNIX), and in 'C:\temp' (on Windows machines.) You can then print out to any postscript printer on UNIX. On windows you can use Adobe Distiller to turn it into an SDF file, and then print it out with Adobe Acrobat. See http://www.adobe.com/supportservice/custsupport/download.html for more information on getting Distiller for both windows and for UNIX.
By now you should have gotten Perl up and running on your machine. Now suppose that you want to get support for your Perl code? There are four major ways to get support: Websites, newsgroups, mailing lists, and professional Perl support. We cover the basics below. We will expand on them in an appendix later on.
There are hundreds of small websites out there dealing with Perl. Ninety-nine percent of your requests can be handled by remembering http://www.perl.com, the Perl home site.
The Perl home page has pretty much anything that you would want about. Pointers to code, CPAN, latest Perl news, answers to frequently asked questions, CGI help and so forth. You will want to start here, and maneuver around a bit inside this massive amount of documentation before doing anything else.
There are several Usenet newsgroups that can help you with Perl. You should be aware of the three most useful.
comp.lang.perl.announce tells about new developments in the Perl community. It is mostly a read-only group. This is one way to find out if a new extension or release of Perl is available.
There is also comp.lang.perl.tk which talks about how to write GUI programs in Perl using the perl/tk extension. It is heavily UNIX based, since tk is currently only a UNIX extension.
Finally, there is comp.www.authoring.cgi which is not strictly Perl, but nonetheless has quite a few Perl programmers and comments, since Perl is the most popular CGI programming language.
Mailing lists tend to be focused, concentrating on specific issues, rather than the gamut of Perl. There are quite a few, some even concentrating on a single Perl module!
However, there is one mailing list that is basic enough to mention right now. This is perl-win32 users@ActiveState.com. If you are a Windows Perl programmer, then this is the place to go for information. Make a message with the message body:
SUBSCRIBE perl-win32-users
or, if you want the digest form:
DIGEST perl-win32-users
and send it to ListManager@ActiveState.com.
In addition, perlbug@perl.com is a place for reporting Perl bugs. Perl has a nice interface called perlbug which is included in the distribution. Type:
prompt% perlbug
to report a given bug. This script does everything for you; reports the version, particulars, etc. The only thing you have to do is write the bug! The script will even mail it for you.
Perl has pretty much integrated itself into the enterprise and there are a number of companies out there where you can get contracts for Perl support.
The company I work for - ApexTech - has technical support contracts available for perl, specializing in C++ and perl support for the enterprise. We also maintain a perl 'help' desk, at perlhelp@apxtech.com, which can help answer any simple perl question that you might have, or point you to the right place for a solution. Mail to perlhelp@apxtech.com for more details, or point your browser at http://www.apxtech.com/perl.
For information on professional training classes, simply point your browser to http://www.perl.com/perl (again the Perl home page). Tom Christiansen has been doing Perl training courses for years, and he maintains the most popular website for Perl. Email perl-classes@perl.com for more information.
Another good site for professional Perl support is http://www.perl.co.uk, 'The Perl Clinic'. It is headed up by Tim Bunce who has done a lot of work tying Relational Databases and Perl together, as well as doing core work in making Perl as useful as it is today. Email perl-support-info@perl.co.uk for more information.
I haven't done much research on this subject, but given that the company I work for does it and (as far as I know) my company is not unique, there are probably quite a few other sources. Cygnus software (www.cygnus.com) and ActiveState (www.activestate.com) might have more information.
We covered quite a bit in this chapter, and here is a checklist of things that you should have completed at this point in order to get the most out of this book and your learning efforts:
1) You should have made and installed Perl, by the flowchart given at the top of the chapter.
2) You should have ready access to the Perl documentation.
3) You should have perused a couple of on-line sites, especially http://www.perl.com/perl. If you are using Win32, http://ActiveState.com.
Now that you have Perl installed, the documentation in an accessible place, and subscribed to a mailing list or news group, what happens next? The next chapter gets you started on programming in Perl by giving a very high level overview of the Perl 5 development environment. After that, we get into brass tacks, going through a lot of examples of how Perl works, and actual scripts that will work on both NT and UNIX. This is the job of chapters 3-11.
So take it nice and easy (and relax!). We've got a lot of ground to cover, but fortunately we've got a lot of space to do it in. Next, a high-level overview of what this Perl thing is all about.
![]() ![]() |
![]() ![]() |
![]() ![]() |
COMPUTING MCGRAW-HILL | Beta Books | Contact Us | Order Information | Online Catalog
HTML conversions by Mega Space.
This page updated on October 14, 1997 by Webmaster.
Computing McGraw-Hill is an imprint of the McGraw-Hill Professional Book Group.
Copyright ©1997 The McGraw-Hill Companies, Inc. All Rights Reserved.
Any use is subject to the rules stated in the
Terms of Use.