The perl executable, normally installed in /usr/bin or /usr/local/bin on your machine, is also called the perl interpreter. Every Perl program must be passed through the Perl interpreter in order to execute. The first line in many Perl programs is something like:
#!/usr/bin/perl
For Unix systems, this #!
(hash-bang or shebang) line
tells the shell to look for the
/usr/bin/perl program and pass the rest of the file
to that program for execution. Sometimes you'll see different
pathnames to the Perl executable, such as /usr/local/bin/perl.
You might see perl5 instead of perl on sites that still depend
on older versions of Perl.
Or you'll see command-line options tacked on the end, such as
the notorious -w switch, which produces warning messages.
But almost all Perl programs
on Unix start with some variation of this line.
If you get a mysterious
"Command not found" error on a Perl program, it's
often because the path to the Perl executable is wrong.
When you download Perl programs off the Internet, copy them
from one machine to another, or copy
them out of a book (like this one!), the first thing you
should do is make sure that the #!
line points to the
location of the Perl interpreter on your system.
So what does the Perl interpreter do? It compiles the program internally into a parse tree and then executes it immediately. Perl is commonly known as an interpreted language, but this is not strictly true. Since the interpreter actually does convert the program into byte code before executing it, it is sometimes called an interpreter/compiler, if anything at all. [1] Although the compiled form is not stored as a file, release 5.005 of Perl includes a working version of a standalone Perl compiler.
[1] So do you call something a Perl "script" or a Perl "program"? Typically, the word "program" is used to describe something that needs to be compiled into assembler or byte code before executing, as in the C language, and the word "script" is used to describe something that runs through an interpreter, as in the Bourne shell. For Perl, you can use either phrase and not worry about offending anyone.
What does all this brouhaha mean for you? When you write a Perl program,
you can just give it a correct #!
line at the top of
the script, make it executable with chmod +x
, and run it.
For 95% of Perl programmers in this world, that's all you'll
care about.
In addition to specifying a #!
line, you can also
specify a short script directly on the command line.
Here are some of the possible ways to run Perl:
Issue the perl command, writing your script line by line via -e switches on the command line:
perl -e 'print "Hello, world\n"' #Unix perl -e "print \"Hello, world\n\"" #Win32
Issue the perl command, passing Perl the name of your script as the first parameter (after any switches):
perl testpgm
On Unix systems that support the #!
notation, specify
the Perl command on the #!
line, make your
script executable, and invoke it from the shell
(as described above).
Pass your script to Perl via standard input. For example, under Unix:
echo "print 'Hello, world'" | perl -
or (unless ignoreeof
is set):
% perl print "Hello, world\n"; ^D
On Win32 systems, you can associate an extension (e.g., .plx) with a file type and double-click on the icon for a Perl script with that file type. If you are using the ActiveState version of Win32 Perl, the installation script normally prompts you to create the association.
On Win32 systems, if you double-click on the icon for the Perl executable, you'll find yourself in a command-prompt window, with a blinking cursor. You can enter your Perl commands, indicating the end of your input with CTRL-Z, and Perl will compile and execute your script.
Perl parses the input file from the
beginning, unless you've specified the -x switch (see the section
"Command-Line Options" below).
If there is a #!
line, it is always examined for
switches as the line is being parsed. Thus,
switches behave consistently regardless of how Perl was invoked.
After locating your script, Perl compiles the entire script into an
internal form. If there are any compilation errors, execution of the
script is not attempted. If the script is syntactically correct,
it is executed. If the script
runs off the end without hitting an exit
or die
operator, an implicit
exit(0)
is provided to indicate successful completion.
Copyright © 2001 O'Reilly & Associates. All rights reserved.