Writing and Running Your First Script

Part I · Module 1 · Chapter 1.3 · Writing and Running Your First Script

1. Why a File, and Not a One-Liner

Chapter 1.2 finished with a program typed straight at the prompt:

perl -e 'print "Perl works\n"'

That was the right tool for its job — proving the interpreter runs code. It is the wrong tool for everything after it, for four reasons that matter more in engineering than in learning:

• It cannot be reviewed. A colleague cannot read a command you typed and deleted.
• It cannot be versioned. There is nothing for Git to track, so there is no history and no way to see what changed when the output changed.
• It cannot be re-run reliably. Shell history is not a record of intent, and quoting rules make long one-liners fragile.
• It cannot be scheduled. A nightly job runs a file, not something you typed once.

A file fixes all four. The file is the unit of work for the rest of this course and the rest of your career with Perl, so it is worth getting the mechanics completely solid now.

2. Creating the File

Open any text editor and create a file named check.pl containing exactly this:

use strict;
use warnings;

print "check starting\n";

Nothing here is new. print, the double-quoted text, \n and the semicolon were all explained in Chapter 1.1, and use strict / use warnings are the two settings you put at the top of every script — Chapters 1.10 and 1.11 explain exactly what each one catches.

Two practical points about the file itself:

• It is plain text. Any editor that saves plain text will do. A word processor will not: it saves formatting, and Perl will choke on it.
• Save it in a directory you can find again. §6 shows what happens when you cannot, and it is the most common first-day problem.

3. Running It

Hand the file to the interpreter, exactly as you handed it -e before:

perl check.pl

check starting

That is the whole mechanism. perl is the program; check.pl is the argument telling it which file to read. The name check.pl has no special status — it is just the file you happened to create, and §7 covers what the .pl is really for.

4. The Edit–Save–Run Cycle

Now change the file. Add a second line so it reads:

use strict;
use warnings;

print "check starting\n";
print "check finished\n";

Save it, and run the same command again:

perl check.pl

check starting
check finished

You have just completed the loop you will spend the rest of Part I inside.

5. What "No Output" Actually Means

Three situations look the same in the terminal and have different causes. Being able to separate them is worth more than any syntax you learn today.

An empty file is a valid program. Create a file with nothing in it and run it:

perl empty.pl

Nothing prints, and Perl is perfectly happy — it compiled a program containing no instructions and carried out all none of them. There is no error, because nothing is wrong. A program that does nothing is a legitimate program.

A program with no print also prints nothing. This surprises beginners who expect a script to report on itself. Perl displays exactly what you asked it to display and nothing else: no automatic summary, no confirmation that it ran.

A missing file is a different thing entirely, and Perl says so — see §6.

The distinction to carry forward: silence is not failure. If you want to know a script ran, make it say so. That is why check.pl prints check starting rather than computing something quietly, and it is a habit worth keeping in real automation.

6. Where the File Has to Be

perl check.pl means "read the file called check.pl in the directory I am currently in." Move to a different directory and the same command fails:

Can't open perl script "check.pl": No such file or directory

Perl also stops with a non-zero exit status here, which is how a calling script or a scheduled job can tell the difference between "ran and printed nothing" and "never ran at all". Exit statuses get their own treatment in Module 15.

Read that message carefully, because it is precise: Perl is not saying the script is wrong. It is saying it never found a script to read. Two things produce it:

• You are in the wrong directory. Check with pwd, and list the files with ls.
• The name does not match. A typo gives exactly the same message:

Can't open perl script "chekc.pl": No such file or directory

You can also give Perl a path instead of moving: perl /full/path/to/check.pl works from anywhere. That becomes important the moment something other than you runs the script, which is the subject of Chapter 1.4.

7. What the Filename Does and Does Not Mean

The .pl ending is a convention for humans and editors, not a rule the system enforces. Proof: copy check.pl to check.pl.txt and run it, and it works exactly the same. Perl reads whatever file you name and does not inspect the extension.

So why use .pl at all? Three reasons, all social rather than technical:

• Your editor uses it to decide how to colour the text.
• Your colleagues use it to know what the file is without opening it.
• Tooling — linters, review scripts, search — uses it to find Perl files in a tree.

Modules get .pm and scripts get .pl by the same convention. Neither is enforced, and both are worth following.

8. Mistakes on the First Day

Beyond the save-and-rerun trap in §4 and the directory problem in §6, two more are common.

A word processor instead of a text editor. The file looks right on screen and contains formatting bytes Perl cannot parse. The symptom is a syntax error on line 1 of a file that looks obviously fine. The fix is a plain-text editor.

Expecting the editor's "run" button to be the same thing. Many editors can run a script for you, which is convenient and hides which interpreter was used and which directory it ran in — the two things Chapter 1.2 spent its whole length teaching you to check. Run from a shell while you are learning. Use the button later, once you know what it is doing on your behalf.

9. Why This Matters in Engineering Work

A file, rather than a typed command, is what makes automation possible at all. Everything a chip-design group automates overnight is a file somewhere: the thing that launches a simulation, the thing that reads its output, the thing that mails a summary. The reason is exactly the four properties in §1 — reviewable, versioned, repeatable, schedulable.

There is a second, quieter reason that matters more than it sounds. When a result is questioned months later — a run that passed and should not have — the question is always "what exactly did it do?". A file answers that. A command someone typed does not. The habit of putting work in a file, with a name that says what it does, is the first of several habits in this course that exist to make results defensible rather than merely correct.

10. What You Should Be Able to Say Now

1. perl check.pl tells the interpreter to read and run the file named check.pl in the current directory.
2. The loop is edit, save, run, read — and Perl reads the saved file, not the editor buffer.
3. A program that prints nothing has not failed; an empty file is a valid program that succeeds.
4. Can't open perl script means the file was never found — wrong directory or wrong name — not that the code is wrong.
5. The .pl extension is a convention for people and tools, not a requirement.

11. Exercise

Everything needed is in this chapter and the two before it.

Exercise 1 — make the cycle yours. Create check.pl from §2, run it, then change the message to something of your own and run it again. Confirm the new text appears. Then make a change, do not save, and run it once more: write down what you see and why.

Exercise 2 — predict before you run. Create a file containing only the two lines use strict; and use warnings;, with no print. Predict what running it will show, and whether it will report an error. Then run it and compare.

Exercise 3 — produce the error on purpose. Run perl check.pl from a different directory, so you see the Can't open perl script message yourself. Then run it successfully from that same directory without moving, by giving Perl the full path to the file.

Exercise 4 — reason about the extension. Rename your script to check.perl and run it. Explain, in one sentence, why it still works and why you should rename it back anyway.

12. Summary

• A file is the unit of work. One-liners prove the interpreter runs; files can be reviewed, versioned, re-run and scheduled, which is what automation requires.
• The loop is edit, save, run, read. Perl reads the file on disk, so an unsaved edit means you are running the old version.
• Silence is not failure. A script prints only what you tell it to, and an empty file is a valid program that succeeds with no output.
• Can't open perl script is a different class of problem — the file was never found. Check the directory and the spelling, or give a full path.
• The .pl extension is convention, not enforcement, and worth following for the sake of your editor, your colleagues and your tooling.

You can now write a program, run it and tell its silence apart from its failure. Chapter 1.4 removes the need to type perl in front of it, by putting a first line in the file that tells the system which interpreter to use.