ch01_04.htm

来自「by Randal L. Schwartz and Tom Phoenix I」· HTM 代码 · 共 361 行 · 第 1/2 页

"sh-bang" mechanism was introduced somewhere in the
mid-1980s, and that's pretty ancient, even on the extensively
long Unix timeline.</p> </blockquote>

<p>This <tt class="literal">#!</tt> line is actually the least portable part
of a Perl program, because you'll need to find out what goes
there for each machine. Fortunately, it's almost always either
<em class="filename">/usr/bin/perl</em><a name="INDEX-84" />
or
<em class="filename">/usr/local/bin/perl</em><a name="INDEX-85" />.
If you find that it's not, you can cast a magic spell on your
system administrator to fix things. Just say "You know, I read
in a book that both <em class="filename">/usr/bin/perl</em> and
<em class="filename">/usr/local/bin/perl</em> should be symbolic links to
the true Perl binary," and under the influence of your spell
the admin will make everything work. All of the example programs
you're likely to find on the Net and elsewhere will begin with
one of those two forms.
</p>

<p>On non-Unix systems, it's traditional (and even useful) to make
the first line say
<tt class="literal">#!perl</tt><a name="INDEX-86" />.
If nothing else, it tells your maintenance programmer as soon as he
or she gets ready to fix it that it's a Perl program.
</p>

<p>If that <tt class="literal">#!</tt> line is wrong, you'll generally
get an error from your shell. This may be something unexpected, like
"file not found." It's not your program
that's not found, though; it's
<em class="filename">/usr/bin/perl</em> that wasn't where it should
have been. We'd make the message clearer, but it's not
coming from Perl; it's the shell that's complaining. (By
the way, you should be careful to spell it <em class="filename">usr</em>
and not <em class="filename">user</em> -- the folks who invented Unix
were lazy typists, so they omitted a lot of letters.)
</p>

<p>Another problem you could have is if your system doesn't
support the <tt class="literal">#!</tt> line at all. In that case, your
shell (or whatever your system uses) will probably try to run your
program all by itself, with results that may disappoint or astonish
you. If you can't figure out what some strange error message is
telling you, search for it in the
<em class="emphasis">perldiag</em><a name="INDEX-87" /> manpage.
</p>

<p>The <a name="INDEX-88" />"main" program consists of
all of the ordinary Perl statements (not including anything in
subroutines, which we'll see later). There's no
"main" routine, as there is in languages like C or Java.
In fact, many programs don't even have routines (in the form of
subroutines).
</p>

<p>There's also no required variable declaration section, as there
is in some other languages. If you've always had to declare
your
<a name="INDEX-89" />variables,
you may be startled or unsettled by this at first. But it allows us
to write "quick-and-dirty" Perl programs. If your program
is only two lines long, you don't want to have to use one of
those lines just to declare your variables. If you really want to
declare your variables, that's a good thing; we'll see
how to do that in <a href="ch04_01.htm">Chapter 4, "Subroutines"</a>.
</p>

<p>Most statements are an expression followed by a
<a name="INDEX-90" /> <a name="INDEX-91" />semicolon.
Here's the one we've seen a few times so far:
</p>

<blockquote><pre class="code">print "Hello, world!\n";</pre></blockquote>

<p>As you may have guessed by now, this line prints the message
<tt class="literal">Hello,</tt> <tt class="literal">world!</tt> At the end of
that message is the shortcut
<tt class="literal">\n</tt><a name="INDEX-92" />, which is probably familiar to you if
you've used another language like C, C++, or Java; it means a
newline character. When that's printed after the message, the
print position drops down to the start of the next line, allowing the
following shell prompt to appear on a line of its own, rather than
being attached to the message. Every line of output should end with a
newline character. We'll see more about the newline shortcut
and other so-called <a name="INDEX-93" />backslash escapes in the next chapter.
</p>

</div>
<a name="lperl3-CHP-1-SECT-4.3" /><div class="sect2">
<h3 class="sect2">1.4.3. But How Do I Compile Perl?</h3>

<p>You may be surprised to learn that all you have to do to
<a name="INDEX-94" />
<a name="INDEX-95" />compile
Perl is to run it. When you run your program, Perl's internal
compiler first runs through your entire source, turning it into
internal
<em class="firstterm">bytecodes</em><a name="INDEX-96" />
(an internal data structure representing the program); then
Perl's bytecode engine actually runs them.<a href="#FOOTNOTE-35">[35]</a>
</p><blockquote class="footnote"> <a name="FOOTNOTE-35" /><p>[35]As
usual, there's more to the story than what we say here. But
this should be close enough for all but the technically advanced
folks, and they already know about this.</p> </blockquote>

<p>So, if there's a syntax error on line 200, you'll get
that error message before you start running line two.<a href="#FOOTNOTE-36">[36]</a> If you have a loop that runs 5000
times, it's compiled just once; the actual loop can then run at
top speed. And there's no runtime penalty for using as many
comments and as much whitespace as you need to make your program easy
to understand. You can even use calculations involving only
constants, and the result is a constant computed once as the program
is beginning -- not each time through a loop.
</p><blockquote class="footnote">
<a name="FOOTNOTE-36" /><p>[36]Unless line two happens to be a compile-time operation, like a
<tt class="literal">BEGIN</tt> block or a <tt class="literal">use</tt>
invocation.</p> </blockquote>

<p>To be sure, this compilation does take time -- it's
inefficient to have a voluminous Perl program that does one small
quick task (out of many potential tasks, say) and then exits, because
the <a name="INDEX-97" />runtime for the
program will be dwarfed by the compile time. But the compiler is very
fast; normally the compilation will be a tiny percentage of the
runtime.
</p>

<p>An exception might be if you were writing a program to be run over
the <a name="INDEX-98" />
<a name="INDEX-99" />
<a name="INDEX-100" />Web,
where it may be called hundreds or thousands of times every minute.
(This is a very high usage rate. If it were called a few hundreds or
thousands of times per <em class="emphasis">day</em>, like most programs
on the Web, we probably wouldn't worry too much about it.) Many
of these programs have very short runtimes, so the issue of
recompilation may become significant. If this is an issue for you,
you'll want to find a way to keep your program resident in
memory between invocations (whether it's written in Perl or
not); see the documentation for your web server and ask your local
expert for help with this.<a href="#FOOTNOTE-37">[37]</a>
</p><blockquote class="footnote"> <a name="FOOTNOTE-37" /><p>[37]Point your local expert to
<a href="http://perl.apache.org">http://perl.apache.org</a>for one
possible solution.</p> </blockquote>

<p>What if you could save the compiled bytecodes to avoid the overhead
of compilation? Or, even better, what if you could turn the bytecodes
into another language, like C, and then compile that? Well, both of
these things are possible (although beyond the scope of this book),
although they won't make most programs any easier to use,
maintain, debug, or install, and they may (for somewhat technical
reasons) make your program even slower.<a href="#FOOTNOTE-38">[38]</a> We
don't know anyone who has ever needed to compile a Perl program
(except for experimental purposes), and we doubt you ever will ever
meet one, either.<a name="INDEX-101" /> 
</p><blockquote class="footnote"> <a name="FOOTNOTE-38" /><p>[38]On many
(perhaps most) systems where you might want to compile a Perl
program, the perl binary (the program that executes your Perl
programs) is always in use by some process, so it's always
resident in memory. A "compiled Perl" program will take
time to load into memory. If it's a small program, it would
probably compile at least as fast as it takes to load a compiled
executable. If it's a large one, compilation is probably an
insignificant part of its runtime anyway.</p> </blockquote>

</div>


<hr width="684" align="left" />
<div class="navbar"><table width="684" border="0"><tr><td align="left" valign="top" width="228"><a href="ch01_03.htm"><img alt="Previous" border="0" src="../gifs/txtpreva.gif" /></a></td><td align="center" valign="top" width="228"><a href="index.htm"><img alt="Home" border="0" src="../gifs/txthome.gif" /></a></td><td align="right" valign="top" width="228"><a href="ch01_05.htm"><img alt="Next" border="0" src="../gifs/txtnexta.gif" /></a></td></tr><tr><td align="left" valign="top" width="228">1.3. How Can I Get Perl?</td><td align="center" valign="top" width="228"><a href="index/index.htm"><img alt="Book Index" border="0" src="../gifs/index.gif" /></a></td><td align="right" valign="top" width="228">1.5. A Whirlwind Tour of Perl</td></tr></table></div>
<hr width="684" align="left" />

<img alt="Library Navigation Links" border="0" src="../gifs/navbar.gif" usemap="#library-map" />
<p><p><font size="-1"><a href="copyrght.htm">Copyright &copy; 2002</a> O'Reilly &amp; Associates. All rights reserved.</font></p>

<map name="library-map"><area shape="rect" coords="1,0,85,94" href="../index.htm"><area shape="rect" coords="86,1,178,103" href="../lwp/index.htm"><area shape="rect" coords="180,0,265,103" href="../lperl/index.htm"><area shape="rect" coords="267,0,353,105" href="../perlnut/index.htm"><area shape="rect" coords="354,1,446,115" href="../prog/index.htm"><area shape="rect" coords="448,0,526,132" href="../tk/index.htm"><area shape="rect" coords="528,1,615,119" href="../cookbook/index.htm"><area shape="rect" coords="617,0,690,135" href="../pxml/index.htm"></map>

</body></html>