A shell script is nothing more than a sequence of shell commands stuffed into a text file. The file is then " made executable" by turning on the execute bit (via chmod +x filename ) and then the name of the file is typed at a shell prompt. Bingo, one shell program. For example, a script to run the date command followed by the who command can be created and executed like this:
Similarly, a Perl program is a bunch of Perl statements and definitions thrown into a file. You then turn on the execute bit[ 2 ] and type the name of the file at a shell prompt. However, the file has to indicate that this is a Perl program and not a shell program, so you need an additional step.
Most of the time, this step involves placing the line
as the first line of the file. But if your Perl is stuck in some nonstandard place, or your system doesn't understand the
Perl is mostly a free-format language like C -
whitespace between tokens (elements of the program, like
Although nearly any Perl program can be written all on one line, typically a Perl program is indented much like a C program, with nested parts of statements indented more than the surrounding parts. You'll see plenty of examples showing a typical indentation style throughout this book.
Unlike most shells (but like awk and sed ), the Perl interpreter completely parses and compiles the program into an internal format before executing any of it. This means that you can never get a syntax error from the program once the program has started, and that the whitespace and comments simply disappear and won't slow the program down. This compilation phase ensures the rapid execution of Perl operations once it is started, and it provides additional motivation for dropping C as a systems utility language merely on the grounds that C is compiled.
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) and then exits, because the run-time for the program will be dwarfed by the compile-time.
So Perl is like a compiler and an interpreter. It's a compiler because the program is completely read and parsed before the first statement is executed. It's an interpreter because there is no object code sitting around filling up disk space. In some ways, it's the best of both worlds. Admittedly, a caching of the compiled object code between invocations, or even translation into native machine code, would be nice. Actually, a working version of such a compiler already exists and is currently scheduled to be bundled into the 5.005 release. See the Perl FAQ for current status.