1.4. How Do I Make a Perl Program? It's about time you asked (even if you didn't). Perl programs are text files; you can create and edit them with your favorite text editor. (You don't need any special development environment, though some commercial ones are available from various vendors. We've never used any of these enough to recommend them.) You should generally use a programmers' text editor, rather than an ordinary editor. What's the difference? Well, a programmers' text editor will let you do things that programmers need, like indent or unindent a block of code or to find the matching closing curly brace for a given opening curly brace. On Unix systems, the two most popular programmers' editors are emacs and vi (and their variants and clones). BBEdit and Alpha are good editors for Mac OS X, and a lot of people have said nice things about UltraEdit and Programmer's Favorite Editor (PFE) on Windows. The perlfaq2 manpage lists several other editors, too. Ask your local expert about text editors on your system. For the simple programs you'll write for the exercises in this book, none of which should be more than about twenty or thirty lines of code, any text editor will be fine. A few beginners try to use a word processor instead of a text editor. We recommend against this because it's inconvenient at best and impossible at worst. But we won't try to stop you. Be sure to tell the word processor to save your file as "text only"; the word processor's own format will almost certainly be unusable. Most word processors will probably tell you that your Perl program is spelled incorrectly and should use fewer semicolons. In some cases, you may need to compose the program on one machine and transfer it to another to run it. If you do this, be sure that the transfer uses "text" or "ASCII" mode and not "binary" mode. This step is needed because of the different text formats on different machines. Without that, you may get inconsistent results. Some versions of Perl abort when they detect a mismatch in the line endings. 1.4.1. A Simple Program According to the oldest rule in the book, any book about a computer language that has Unix-like roots has to start with showing the "Hello, world" program. So, here it is in Perl: #!/usr/bin/perl print "Hello, world!\n";
Let's imagine that you've typed that into your text editor. (Don't worry yet about what the parts mean and how it works. We'll see about those in a moment.) You can generally save that program under any name you wish. Perl doesn't require any special kind of filename or extension, and it's better to use no extension at all.[*] But some systems may require an extension like .plx (meaning PerL eXecutable); see your system's release notes for more information. [*] Why is it better to have no extension? Imagine that you've written a program to calculate bowling scores and you've told all of your friends that it's called bowling.plx. One day you decide to rewrite it in C. Do you still call it by the same name, implying that it's still written in Perl? Or do you tell everyone that it has a new name? (And don't call it bowling.c, please!) The answer is that it's none of their business what language it's written in if they're merely using it. So, it should have simply been called bowling in the first place.
You may need to do something so your system knows it's an executable program (that is, a command). What you'll do depends upon your system; maybe you won't have to do anything more than to save the program in a certain place. (Your current directory will generally be fine.) On Unix systems, you mark a program as being executable by using the chmod command, perhaps like this: $ chmod a+x my_program
The dollar sign (and space) at the start of the line represents the shell prompt, which will probably look different on your system. If you're used to using chmod with a number like 755 instead of a symbolic parameter like a+x, that's fine, too. Either way, it tells the system that this file is now a program. Now you're ready to run it: $ ./my_program
The dot and slash at the start of this command mean to find the program in the current working directory. That's not needed in all cases, but you should use it at the start of each command invocation until you fully understand what it's doing.[*] If everything worked, it's a miracle. More often, you'll find that your program has a bug. Edit and try again, but you don't need to use chmod each time since that should "stick" to the file. (Of course, if the bug is that you didn't use chmod correctly, you'll probably get a "permission denied" message from your shell.) [*] In short, it's preventing your shell from running another program (or shell built-in) of the same name. A common mistake among beginners is to name their first program test. Many systems have a program (or shell built-in) with that name; that's what the beginners run instead of their program.
1.4.2. What's Inside That Program? Like other "free-form" languages, Perl generally lets you use insignificant whitespace (like spaces, tabs, and newlines) at will to make your program easier to read. Most Perl programs use a fairly standard format though, much like most of what we show here. We strongly encourage you to indent your programs properly since that makes your program easier to read; a good text editor will do most of the work for you. Good comments make a program easier to read. In Perl, comments run from a pound sign (#) to the end of the line. (There are no "block comments" in Perl.)[ ] We dont use many comments in the programs in this book because the surrounding text explains their workings, but you should use comments as needed in your own programs. [] But there are a number of ways to fake them. See the FAQ (accessible with So another way (a strange way, it must be said) to write that same "Hello, world" program might be like this: #!/usr/bin/perl print # This is a comment "Hello, world!\n" ; # Don't write your Perl code like this!
That first line is a special comment. On Unix systems,[*] if the first two characters on the first line of a text file are "#!", then what follows is the name of the program that executes the rest of the file. In this case, the program is stored in the file /usr/bin/perl. [*] Most modern ones, anyway. The "shebang" mechanism pronounced "sheh-bang," as in "the whole shebang" was introduced somewhere in the mid-1980s, and that's pretty ancient, even on the extensively long Unix timeline.
This #! line is 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 /usr/bin/perl or /usr/local/bin/perl. If that's not it, you'll have to find where your system is hiding perl and use that path. On Unix systems, you might use a shebang line that finds perl for you: #!/usr/bin/env perl
If perl isn't in any of the directories in your search path, you might have to ask your local system administrator or somebody using the same system as you. On non-Unix systems, it's traditional (and even useful) to make the first line say #!perl. 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. If that #! 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 /usr/bin/perl 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 usr and not user because the folks who invented Unix were lazy typists, so they omitted a lot of letters.) Another problem you could have is if your system doesn't support the #! line at all. In that case, your shell (or whatever your system uses) will probably run your program 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 perldiag manpage. The "main" program consists of all of the ordinary Perl statements (not including anything in subroutines, which you'll see later). There's no "main" routine, as there is in languages like C or Java. In fact, many programs don't have routines (in the form of subroutines). There's no required variable declaration section as there is in some other languages. If you've always had to declare your 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 want to declare your variables, that's a good thing; you'll see how to do that in Chapter 4. Most statements are an expression followed by a semicolon. Here's the one you've seen a few times so far: print "Hello, world!\n";
As you may have guessed by now, this line prints the message Hello, world!. At the end of that message is the shortcut \n, 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 backslash escapes in the next chapter. 1.4.3. How Do I Compile Perl? Just run your Perl program. The perl interpreter compiles and then runs your program in one user step. $ perl my_program
When you run your program, Perl's internal compiler first runs through your entire source, turning it into internal bytecode, which is an internal data structure representing the program. Perl's bytecode engine takes over and runs the bytecode. If there's a syntax error on line 200, you'll get that error message before you start running line two.[*] If you have a loop that runs 5,000 times, it's compiled once; the 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. If you use calculations involving only constants the result will be a constant computed once as the program is beginning, not each time through a loop. [*] Unless line two happens to be a compile-time operation, like a BEGIN block or a use invocation.
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 runtime for the program will be dwarfed by the compile time. But the compiler is fast; normally the compilation will be a tiny percentage of the runtime. An exception might be if you were writing a program run as a CGI script, where it may be called hundreds or thousands of times every minute. (This is a high usage rate. If it were called a few hundreds or thousands of times per day, like most programs on the Web, we probably wouldn't worry too much about it.) Many of these programs have 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 in memory between invocations. The mod_perl extension to the Apache web server http://perl.apache.org or Perl modules like CGI::Fast can help you. What if you could save the compiled bytecode to avoid the overhead of compilation? Or, even better, what if you could turn the bytecode into another language, like C, and then compile that? Well, both of these things are possible in some cases, but they probably won't make most programs any easier to use, maintain, debug, or install, and they may make your program slower. Perl 6 should do a lot better in this regard, although it is too soon to tell (as we write this).
| 