How Perl Executes Your Program

Part I · Module 1 · Chapter 1.5 · How Perl Executes Your Program

1. Two Stages, and Why the Order Matters

When you run perl check.pl, Perl does two separate things in sequence:

1. Compile. It reads the whole file, works out what every statement means, and builds an internal form of the program. If any part of the file cannot be understood, it stops here.
2. Run. Only if the first stage succeeded does it carry out the instructions, in order, from the top.

Chapter 1.1 stated that model. The rest of this chapter demonstrates it, because the consequence is genuinely useful and not obvious: a mistake at the end of your file can prevent the beginning of your file from producing any output.

A reader who believes Perl works line by line cannot explain that, and will waste time looking for a fault in code that never ran.

2. A Fault Found While Compiling

Here is a program whose only problem is a missing semicolon on line 4:

use strict;
use warnings;
print "first\n";
print "second\n"
print "third\n";

Run it, and look carefully at what does not happen:

syntax error at compile-fault.pl line 5, near "print"
Execution of compile-fault.pl aborted due to compilation errors.

first was never printed, even though its print is on line 3, above the fault, and is a perfectly correct statement. Measured directly, Perl exits with status 255.

That is stage 1 refusing to finish. Perl never reached stage 2, so none of your instructions ran — not even the ones it had already understood. The phrase aborted due to compilation errors is Perl telling you exactly that.

3. A Fault Found While Running

Now a program with correct syntax throughout, which fails once it is already running. It uses one new word, die, which means "stop now and print this message as an error" — Chapter 14.2 covers it properly:

use strict;
use warnings;
print "first\n";
die "stopping here\n";
print "never reached\n";

first

stopping here

This time first did print. Perl compiled the whole file successfully, began running it, carried out line 3, reached line 4 and stopped. Line 5 never ran. The exit status is again 255.

So two programs, both exiting 255, with completely different stories: one never started, the other got part way. Telling them apart costs nothing once you know to look.

4. Proving Stage 1 on Its Own

Perl will do the first stage and stop, if you ask. That is what -c means — Chapter 1.13 is devoted to it:

perl -c run-fault.pl

run-fault.pl syntax OK

Note what just happened: run-fault.pl is the program that dies when you run it, and perl -c pronounced it fine and exited 0. It is not wrong to do so — the program is syntactically valid, and die is a legitimate instruction. -c answers "can this be compiled?", not "will this work?".

Run the same check on the first program and it reports the fault and exits 255:

syntax error at compile-fault.pl line 5, near "print"
compile-fault.pl had compilation errors.

5. What Each Stage Can and Cannot Catch

This table is the chapter in one place.

The practical rule follows from the middle row. If you see no output at all, suspect the syntax of the whole file, not the logic of the first line. If you see partial output, the last thing printed tells you roughly how far it got.

6. The One Exception Worth Knowing

There is a detail here that is easy to state wrongly, so this chapter states it carefully.

use is not an ordinary instruction. It takes effect during compilation, not afterwards — which is how use strict can change the rules Perl applies to the rest of the file while it is still reading it. The consequence is visible when a use cannot be satisfied:

use strict;
use warnings;
print "before\n";
use NoSuchModule::Here;
print "after\n";

Can't locate NoSuchModule/Here.pm in @INC (you may need to install the NoSuchModule::Here module) ... at missing-module.pl line 4.
BEGIN failed--compilation aborted at missing-module.pl line 4.

before never printed, even though its print is above the failing line. Perl's own wording gives the game away: compilation aborted. The use was acted on while compiling, it failed, and the program never reached stage 2.

So the precise statement is: your program's ordinary instructions do not begin until the whole file has compiled — and use is the exception, because it is part of compiling. You do not need more detail than that in Part I. It is enough to explain why a missing module gives you no output whatsoever.

7. Diagnosing With This Model

Three situations, and what the model tells you immediately.

No output, and a message mentioning a line number. Stage 1 failed. Nothing you wrote ran. Go to the line named — and, as Chapter 1.12 covers, check the line above it too, because Perl reports where it noticed the problem rather than where it is.

Some output, then a message. Stage 2 failed. The last line printed is your marker: everything before it completed. This is why print statements are such an effective debugging tool, and why check.pl in Chapter 1.3 announced itself at the start.

No output and no message, exit status 0. Nothing failed. Your program ran and simply did not print anything — the situation Chapter 1.3 covered. Silence is not failure.

8. Why This Matters in Engineering Work

Two practical consequences, both of which Part II relies on.

A syntax check is nearly free, and a run is not. A script that launches a simulation may take hours before it reaches the branch that writes the report. If that branch contains a typo, stage 1 would have caught it in milliseconds — which is the argument for perl -c in Chapter 1.13 and for running it in a pre-merge check.

The error class narrows the search before you read any code. When a nightly job fails, "no output at all" and "output that stops half way" point at completely different causes: the first suggests the script itself is broken or a module is missing on that machine; the second suggests the data or the environment it met. Knowing which one you are looking at is often the fastest step in a triage.

9. What You Should Be Able to Say Now

1. Perl compiles the entire file first, then runs it; the two stages are separate and ordered.
2. A compile fault produces no output at all, however early your correct statements are.
3. A runtime fault produces everything up to the point of failure, so the last line printed tells you how far it got.
4. perl -c performs stage 1 only, and therefore cannot predict a runtime failure.
5. use is acted on during compilation, which is why a missing module also gives you no output.
6. No output with a success status means the program ran and printed nothing — not that it failed.

10. Exercise

Exercise 1 — produce both classes yourself. Write a three-line script that prints one, then two, then three. Run it and confirm all three appear. Now delete the semicolon after two and run it again: record exactly which lines appear, and explain why in terms of the two stages.

Exercise 2 — predict, then check. Put the fault back, and this time replace line 3 with die "stopped\n";. Before running, predict which lines will appear. Then run it and compare.

Exercise 3 — use the right tool. Run perl -c on both versions from Exercise 2. Say which fault it found, which it missed, and why that is the correct behaviour rather than a shortcoming.

Exercise 4 — reason about a report. A colleague says "my script produced no output at all, so the first line must be wrong." Explain, in two sentences, why that conclusion does not follow, and what you would ask to see instead.

11. Summary

• Compile, then run. Perl understands the whole file before carrying out any of your instructions.
• A compile fault prints nothing — not even output from correct statements above the fault. Expect exit status 255 and a message naming a line.
• A runtime fault prints everything up to itself, which makes the last line of output a position marker.
• perl -c is stage 1 only. It proves the file is a valid program; it cannot prove the program works.
• use acts during compilation, so a missing module behaves like a compile fault and produces no output.
• The class of the error narrows the search before you read any of your own code — the habit this chapter exists to build.

You now understand what happens between handing Perl a file and seeing output. Chapter 1.6 goes back to that output and looks properly at the two instructions that produce it, print and say.