ch1.htm

美国Macmillan出版社编写的Perl教程《Perl CGI Web Pages for WINNT》

<LI>Restart your system.
</OL>
<H3><A NAME="SecurityAlert">
Security Alert</A></H3>
<P>
Many administrators have had serious security problems running
Perl on their NT servers. The reason for this is the location
of perl.exe on your system. Figure 1.2 shows the Perl home page
security announcement that outlines the problem, and offers a
solution.
<P>
<A HREF="f1-2.gif" tppabs="http://210.32.137.15/ebook/PC%20Magazine%20Programming%20Perl%205.0%20CGI%20Web%20Pages%20for%20Microsoft%20Windows%20NT/f1-2.gif"><B>Figure 1.2 :</B> <I>Urgent security announcement from the Perl
language home page</I>.</A>
<P>
The following is an urgent security announcement as found on the
Internet:
<P>
How'd you like to let anyone anywhere run any program they feel
like on your system, even sending you new ones of their own devising?
Sound frightening?
<P>
Well, that's what's going on out there.
<P>
Despite months of lobbying corporations, individuals, and the
net at large about the perl.exe?FMH.pl problem, it continues to
get worse. In the spirit of the Satan network checker, here's
something that will help you find out whether you have the problem.
It's called <I>latro</I>, a program that anyone can use to run
any program they feel like on any system so unfortunate as to
have ignored those warnings. If I hadn't written it, someone else
would have.
<P>
You may argue that I've just given a lock-picking kit to the unwashed
masses. Perhaps this is so, but far better that everyone should
have the same resources at their disposal than that merely the
thieves should have them. This way at least the locks might get
fixed.
<P>
Already several people have posted to USENET about how one can
use Alta Vista to find these sites. It's only a matter of time
before these sites get, um, visited. Hopefully someone will construct
a list of these and notify them. This is, of course, just a fraction
of the vulnerable sites.
<P>
Let's clean it up out there, guys. Nefarious users could even
ship over their own PC binaries and run them on your system, which
means that if you aren't careful, they might do something useful
like forcibly upgrade you to Linux. Of course, then the perl.exe?FMH.pl
travesty magically goes away, along with a whole lot of other
problems. :-)
<P>
This problem probably affects only amateur machines: those running
Microsoft or Apple operating systems. UNIX and Plan9 systems should
be largely unaffected, so at least most professional systems should
be safe from this attack. But never underestimate the power of
human stupidity when it comes to using technology they don't understand.
There are also loads of sites out there with other interpreters
than Perl in their cgi-bins, including shells, tcl, Python, and
so forth. This has got to stop.
<P>
CERT has been notified of the issue, and will doubtless deal with
it&nbsp;eventually.
<P>
For more information regarding this security problem please see
Appendix E.
<H2><A NAME="TheImportanceofPerl"><FONT SIZE=5 COLOR=#FF0000>
The Importance of Perl</FONT></A></H2>
<P>
The reasons for choosing Perl as your CGI language are many. The
first is its popularity. There are so many people using it that
the number of Perl libraries is huge and growing every day. Perl
routines are often included in many Web Server packages ready
to use. Often new Internet applications include Perl gateway routines
free of charge.
<P>
There are also numerous areas of support out there, as have been
listed throughout this chapter (even more of which can be found
in Appendix F, &quot;Perl Sources&quot;).
<P>
 These sources include Web sites where Perl creator Larry Wall
(as well as many other key players in Perl's development) has
been known to hold court.
<P>
Finally, Perl routines can be seen to be like mix and match modules
(not to be confused with actual Perl modules, the collections
of scripts). A Perl script can often be used in a new configuration
with an intent never meant for the original script. These smaller
scripts can stay quietly in the library waiting to be used for
many other tasks.
<H3><A NAME="TheDisadvantagesofPerl">
The Disadvantages of Perl</A></H3>
<P>
While you may get caught up in singing the praises of Perl once
you start using it, you should realize that it has limitations.
Perl is ideal for doing what it does, because that's what it was
designed to do. While various industrious individuals are constantly
expanding its powers, Perl is still only a mid-level language
that can't compete with a language like C or C++ when it comes
to bigger applications. At least not yet.
<P>
This section details some of the limitations of Perl from a technical
perspective, and may only make a lot of sense to those of you
with some programming experience. These limitations are important
to note, if only to have for future reference. (This information
is taken from the Perl Home Page's &quot;Seven Deadly Sins of
Perl&quot; article.)
<OL>
<LI><I>Implicit Behaviors and Hidden Context Dependencies</I>-Functions
crash only on return type rather than parameter type. This is
mystifying to the programmer who doesn't have a strong, daily
reinforced understanding of Perl code. Type conversions of the
nonreference variety occur without notification and can be a real
problem, especially between aggregates and scalars. The crashes
are difficult to predict. The presence of less-than-obvious default
behaviors of the various functions (and the inability to turn
this off) can be a bit of a headache.
<LI><I>To Paren || !To Paren?</I>-It is the use of parens, while
allowed in almost every script situation in Perl, that can sometimes
cause major semantic changes in your Perl syntax. Programmers
are confused by whether they should use parens just to be on the
safe side, or leave them out at their own peril. This is especially
trying when having to figure out how to get regular expressions
to return what they match.
<LI><I>Global Variables</I>-There is no mandatory enforcement
of declaration (or detection) of global variables in Perl. This
can make it very difficult to detect program errors. Implicit
use of $_ is one of the usual causes, causing functions further
along the stack to fail for no obvious reason. Strict globals
cannot be used to force declaration, even of the exportable module-level
globals kind. There is, as of yet, no method to have lexically
scoped, predefined file-handles, or Perl's built-in, default variables,
like $_, $?, and the dynamically scoped versions which are confusing
to programmers used to traditional languages.
<LI><I>References versus Nonreferences</I>-Programmers are often
confused about the use of these symbols ($&quot;, @, %) to denote
the different kinds of data structures. In particular, they expect
things that work on same-named arrays or scalars to transparently
work on references to the other, or the other way around. This
problem usually surfaces when scripts are asked to process complex
data structures.
<LI><I>No Prototypes</I>-Not having a prototype feature (function
signatures) makes it impossible to create one's own functions
that exactly duplicate those built-in functions in Perl. It also
makes static analysis of errors difficult. Even when prototypes
for normal functions are introduced, their utility does not work
on user-defined object classes or methods. Perl does not allow
prototypes to return values.
<LI><I>No Compiler Support for I/O or Regular Expression Objects</I>-There
are no really useful compiler-aware support packages for I/O handles.
The open() command and related commands need to be redone in the
source code itself, preferably following an o-o paradigm, but
not so that it interferes with the existing code. The regular
expression system is also outdated. When there is no real compiler
support for compiled regular expressions, you get bad performance
unless you develop scripts, or hacks, to work around the problem.
<LI><I>Haphazard Exception Model</I>-When it comes to dealing
with libraries, modules, or classes, there is not yet a standard
model, or even a guideline. This means you will not be aware of
what to trap and what not to trap. For example, will a library
throw an exception, or will it just return a false value? Even
if it does throw an exception, there is no standard nomenclature
for exceptions, so it's hard to know how, for example, to catch
all numeric exceptions, all i/o exceptions, and so forth. The
eval $str function is often used incorrectly for both code generation
and exception handling, creating delaying errors at run-time and
greatly increasing the chances of losing the generated code.
</OL>
<P>
While these disadvantages to Perl might seem over your head at
the moment, their opaque meaning will come to those who get into
Perl in a big way and then find out that there are limitations.
<H3><A NAME="PerlversusPerl">
Perl 4.0 versus Perl 5.001</A></H3>
<P>
There is still quite a lot of documentation on Perl 4.0 and its
many patch levels. Now that Perl 5.001 is in use, and 5.002 is
not far behind, you might be asking whether you need both to run
old Perl scripts. Perl is designed to incorporate all of its previous
scripts in new releases, so anything you might have, or find,
that was written for any patch level of Perl 4.0 will work with
Perl 5.001.
<H4>To Patch or Not to Patch</H4>
<P>
Patching is what you sometimes do to earlier releases of software
to update it to the current version. It is especially popular
in shareware and freeware. As an NT user you don't need to worry
about patching an old release of Perl because the new 5.001 version
is ready and complete when you download it.
<H3><A NAME="PerlandBeyond">
Perl 5.001 and Beyond</A></H3>
<P>
Already a version of Perl 5.002 is kicking around somewhere. Soon
it will be available, and you can be sure that it will include
even more functionality and fixes of old bugs. The huge ground
support for Perl that exists already, and the communal attitude
Perl developers and programmers share, ensures Perl's continued
use well into the next decade. The time you take learning Perl,
and continuing to develop that knowledge, will not go to waste,
and will be useful for years to come.
<H3><A NAME="GettingStartedwithPerl">
Getting Started with Perl</A></H3>
<P>
Our introduction to Perl has covered quite a few things. We learned
a little about how Perl came from the UNIX world into Windows
NT, creating special translation concerns for NT users to be aware
of. We also touched on how Perl is supported on all levels of
development and programming with newsgroups and Web sites (more
of which are mentioned through the book and in Appendix F), including
the Windows NT port.
<P>
There is also the issue of why Perl is fundamentally a good CGI
language because both Perl and CGI deal with text, a point that
will be expanded on in the chapters to come. Now that you know
where Perl came from and a little bit about what it is, you're
ready to jump right into the language itself.
<HR>

<CENTER><P><A HREF="contents.htm" tppabs="http://210.32.137.15/ebook/PC%20Magazine%20Programming%20Perl%205.0%20CGI%20Web%20Pages%20for%20Microsoft%20Windows%20NT/contents.htm"><IMG SRC="HB.GIF" tppabs="http://210.32.137.15/ebook/PC%20Magazine%20Programming%20Perl%205.0%20CGI%20Web%20Pages%20for%20Microsoft%20Windows%20NT/HB.GIF" BORDER=0 HEIGHT=88 WIDTH=140></A>
<A HREF="#CONTENTS"><IMG SRC="CC.GIF" tppabs="http://210.32.137.15/ebook/PC%20Magazine%20Programming%20Perl%205.0%20CGI%20Web%20Pages%20for%20Microsoft%20Windows%20NT/CC.GIF" BORDER=0 HEIGHT=88 WIDTH=140></A>

<A HREF="ch2.htm" tppabs="http://210.32.137.15/ebook/PC%20Magazine%20Programming%20Perl%205.0%20CGI%20Web%20Pages%20for%20Microsoft%20Windows%20NT/ch2.htm"><IMG SRC="NC.GIF" tppabs="http://210.32.137.15/ebook/PC%20Magazine%20Programming%20Perl%205.0%20CGI%20Web%20Pages%20for%20Microsoft%20Windows%20NT/NC.GIF" BORDER=0 HEIGHT=88 WIDTH=140></A>
<HR WIDTH="100%"></P></CENTER>
</BODY>
</HTML>