Previous Section | Table of Contents | Next Section
This section of the tutorial covers:
The first thing you need to do is log into a Unix shell session. If you already know how to do that, great. Otherwise:
For example, in my case, I start up CRT, choose "File:Connect...", and set up a new profile to take me to "catlow.cyberverse.com" (the hostname of my provider's Unix machine). Using the built-in Windows 95 telnet program, I would just hit the Start button, then choose "Run...", type "telnet catlow.cyberverse.com" into the dialog box, and hit "OK".
Whichever way I get there, I should eventually get a window displaying the following prompt:
login: |
I type in my username, hit enter, then type in my password, and voila, I'm in a Unix shell session:
login: jbc Password: Last login: Tue Sep 1 16:52:11 from pm2-3.sba1.avtel.net 12:14am up 16 days, 7:06, 1 user, load average: 1.74, 1.51, 1.04 catlow:/u1/j/jbc> |
That last line is the Unix command prompt, which in my case has been customized to show the hostname and the path of the current directory. Yours will probably look different; maybe just a percent symbol:
% |
Regardless, you're now in business.
Go ahead and type "perl -v" at your command prompt, then hit enter. If the gods are smiling, you'll get something that looks like the following:
catlow:/u1/j/jbc> perl -v This is perl, version 5.004_01 Copyright 1987-1997, Larry Wall Perl may be copied only under the terms of either the Artistic License or the GNU General Public License, which may be found in the Perl 5.0 source kit. |
If you don't see something like that, then the computer you're logged into doesn't have perl on it, or the perl program isn't in your search path, or something equally annoying. Contact your ISP and bug them until they tell you what's going on.
If you did get a message like the one above, what version of Perl do you have? If it's less than 5.003, and especially if it's version 4-point-something, start bugging your ISP to upgrade it. If they can't or won't do that, get another ISP.
Now let's figure out where perl is located on your system. You'll need to know this later on. Enter the following at the command line:
catlow:/u1/j/jbc> which perl /usr/local/bin/perl |
So, in my case, the perl program is located at /usr/local/bin/perl. (PC users: note the forward slashes - not backslashes - used to separate Unix directory names.)
You have two choices when you want to create a Perl script. You can write it on your desktop PC (or Mac) using whatever text editing program you like, then transfer it to your ISP's Unix server using an FTP program (like WS_FTP for the PC, or Fetch for the Mac) in order to run it. Or, you can write it right there on the Unix machine using a Unix text editor, like pico.
Each approach has its pluses and minuses. Writing scripts on your PC means you can use an editor you're comfortable with (like EditPad, a great free Notepad replacement for Windows users, or BBEdit for you Mac folk, or whatever you like, really, as long as it can save plain ASCII text). You can use your mouse for selecting text, and can work on your script when you're not actually connected to the Internet. The downside is that you'll have to use an FTP program to move your script to the Unix server every time you make a change to it.
Writing your scripts directly on the Unix machine lets you avoid the FTP step. You'll have to gain at least a passing familiarity with a Unix text editor, though, which means learning a bunch of keyboard commands, since you won't be able to do things with your mouse.
The bottom line is, do whatever you're most comfortable with. Personally, I edit on the Unix server for quick-and-dirty scripts, and edit on my local PC for bigger projects.
You probably already dealt with this issue when deciding how to create HTML files for your Web site, so whatever you're doing for those, you can do the same thing for your Perl scripts. There's one important difference, though: If you're creating the scripts on your local PC, then uploading them to your Unix server via FTP, you must make the FTP transfer in "text" mode (sometimes called "ASCII" mode, depending on your FTP program). This doesn't make any real difference when uploading HTML files, but it matters a lot for Perl scripts: If you upload your Perl scripts in "binary" mode, they probably won't work.
Whether you've decided to write your scripts on your local PC or on your Unix server, fire up your text editor. For the following discussion, I'm going to do this on the Unix server, using the pico text editor.
catlow:/u1/j/jbc> pico hello.pl |
This starts up pico, with my cursor at the beginning of a new file called "hello.pl". Now I type the following:
#!/usr/bin/perl # hello.pl - my first perl script! print "Hello, world!\n"; |
Some important points about what's going on here:
The first line is some special magic that will make it easier for you to run your scripts. This needs to be the very first line of your script, and it needs to take the following form: a pound sign (#), then an exclamation point (!), then the path on your system to the perl program itself, which you figured out earlier when you did the "which perl" thing. Just put it there and forget about it. (Unix users sometimes call this a "shebang" line, which for some reason strikes me as funny.)
Note: A reader named Patrick Oostenrijk has written to say I've used the term "pound sign" incorrectly. He says you're supposed to call "#" a "hash sign." All I can say is, you learn something new every day. At Kimberley Elementary School in Redlands, California, U.S.A., where I received my 3rd grade education, "#" was called a "pound sign," and "£" didn't even have a name; I never saw one until high school. You're welcome to call "#" a "hash sign," an "octothorpe," or "that thing that looks like a Tic-Tac-Toe board"; just remember that that's the thing I'm talking about when I say "pound sign." Thanks. :-)
The next line is blank, though it doesn't need to be; that's just to make the script easier to read. In general, Perl ignores blank lines.
The next line is a "comment." In Perl, anything between a pound sign (by which I mean "#") and the end of a line is ignored when you run the script. Comments are useful for making notes to yourself (or whomever else might look at your script later on); it's a good practice to put the name of the script and a brief description of it in a comment up at the top.
Someone is probably wondering about that first line of the script: If perl ignores everything after a #, how does the shebang line do its magic? The answer, Mr. (Ms.) Smarty-boots, is that that first line isn't a Perl thing at all. It's a shell thing. That is, it's there so the Unix shell knows where to find the perl program when you run your script, so it can hand the script off to perl to be interpreted. Like I said, forget about it! :-)
The third line of the script is the part that actually does the work: printing out "Hello, world!", followed by a newline character ("\n"). Note the semicolon (;) that terminates the Perl statement, and the double-quotes (") that surround the string of text to be printed. These are the sorts of persnickety details that will cause problems for you if you're careless in writing your script.
Now let's save the script. In pico, I do that by typing Control-x, then answering "y" when it asks me if I want to save the modified buffer, and then just hitting the Enter key to accept the filename "hello.pl".
If you wrote the script on your local PC, you'll now need to save it and ftp it to your home directory on the Unix server.
The next step is to try running the script by entering its name at the Unix command prompt. I didn't think of this when I first wrote the tutorial, but several helpful folk pointed out that some users might not have the "current" directory (meaning the directory the user is currently "in") in their "command path."
The command path is just a list of directories that the Unix system looks in to find the command you typed in in order to run it. On a DOS system, the current directory is in your command path by default, but not so under Unix.
If the current directory isn't in your command path, typing "hello.pl" will not work, because the Unix shell will not be able to find the script, even though it's right there. Instead, you'll have to type "./hello.pl", with that initial "dot slash" telling the Unix shell to look in the current directory for the command whose name you're typing in.
In this tutorial I will assume that you need the initial "./" to run a script from the command line. You may not need it, though; you can check to see if the current directory is in your command path with the printenv command, as follows:
catlow:/u1/j/jbc> printenv PATH .:/u1/j/jbc/bin:/usr/local/bin:/usr/ucb:/bin:/usr/bin:/usr/5bin:/usr/sbin |
Typing 'printenv PATH' causes the Unix server to print out a colon-separated list of directories that will be searched when you type in a command. If the current directory ( . ) isn't in there, you'll need "./" at the beginning of your script name when you try to run it from the command line
If you get sufficiently annoyed by this, ask your system administrator to tell you how to modify your command path by editing the startup files (the .cshrc file, perhaps) in your home directory.
Now, back at my Unix command prompt, I try typing the name of the script in order to run it:
catlow:/u1/j/jbc> ./hello.pl ./hello.pl: Permission denied. |
Hmmm. Welcome to the world of Unix file permissions. This is probably the trickiest part about running CGI scripts, at least for beginning users.
If you're an impatient sort of person, just type the following command:
catlow:/u1/j/jbc> chmod 700 hello.pl |
and go on to the next topic. If you want to know what's really going on, though, (which I strongly recommend, since it will save you much trouble later on), keep reading.
In Unix, there are three different types of permissions that you can have (or not have) with respect to a particular file: read permission, write permission, and execute permission. Read permission lets you read the file (duh), write permission lets you make changes to it, and execute permission, in the case of a script or program, lets you actually run it.
The three types of permission can be set to "on" or "off" for each of three different sets of people: the file's owner (you, in the case of your scripts), members of the file's group (which we're going to ignore in this discussion), and everyone else in the world (which we're also going to ignore for now, but which will become important in a minute when we try to run hello.pl as a CGI script using the Web server).
You can check the permissions on a file by typing "ls -l" followed by a space and the name of the file. So, to look at the permissions on my hello.pl script:
catlow:/u1/j/jbc> ls -l hello.pl -rw-r--r-- 1 jbc jbc 42 Sep 5 06:55 hello.pl |
The first column in the ls -l listing (the "-rw-r--r--" part) is what tells the story on permissions. That "-rw-r--r--" thing can be decoded as follows:
-rw-r--r-- ^ |
The initial "-" means it's a file (rather than a directory or a link)
-rw-r--r-- ^^^ |
The next three characters ("rw-") mean that the file's owner (me, in this case) has "read" and "write" (but not "execute") permissions.
-rw-r--r--
^^^
|
The next three characters mean that members of the file's group have "read" permission (but not "write" or "execute" permission).
-rw-r--r--
^^^
|
Finally, the last three characters mean that everyone else in the world has "read" permission, but not "write" or "execute" permission.
You change a file's permissions using the Unix command "chmod" (for "change mode"). The chmod command supports a handy shortcut for setting permissions: You express the permissions you want as a three-digit number, like "644" or "755", with the first digit giving the owner's permissions, the second digit giving the group permissions, and the last digit giving the "everybody else" permissions. The numbers themselves are arrived at by simple addition, using the following formula:
4 = read permission
2 = write permission
1 = execute permission
You just add together the numbers corresponding to the permissions you want to allow. For example, for "read plus write" you use the number 6 (because 4 + 2 = 6). "Read, write, and execute" is 7 (becuase 4 + 2 + 1 = 7). No permissions at all is 0 (zero).
Now, remember that the first digit gives the owner's permissions, the second digit gives the group permissions (which we're going to ignore), and the third digit gives the "everybody else" permissions. Thus, "644" means "the file's owner gets read and write permission (4 + 2 = 6), and the group and everyone else each get read permission (4).
These happen to be the permissions that new files get by default when I create them in my Unix shell session, and they are, in fact, the permissions represented by the "-rw-r--r--" I saw in the ls -l listing we were looking at a moment ago.
In order to run hello.pl as a script, we're going to need to turn on the "execute" permission for the file's owner. While we're at it, we may as well turn off all the "group" and "everyone else" permissions, since no one else needs to do anything with this script. We can accomplish all of that with the following command:
catlow:/u1/j/jbc> chmod 700 hello.pl |
Now, checking the permissions we get:
catlow:/u1/j/jbc> ls -l hello.pl -rwx------ 1 jbc jbc 42 Sep 5 06:55 hello.pl |
which is what we want, since now the file's owner (me) has execute permission, as indicated by the "x" in "-rwx------", and the file's group and everyone else have no permissions at all, as indicated by the "------".
Note: I personally find the numeric chmod arguments to be the easiest to use, so that's what I've presented here, but you should be aware that there are also "symbolic" arguments you can use with chmod. If you would rather use something like "chmod u+x hello.pl" instead of "chmod 700 hello.pl", then feel free to go ahead and do things that way. More details on the symbolic chmod arguments are available by typing "man chmod" at the Unix command line.
Now that we've made hello.pl executable by its owner, let's try running it again:
catlow:/u1/j/jbc> ./hello.pl Hello, world! |
Congratulations! You've just run your first Perl script.
Previous Section | Table of Contents | Next Section
John Callender
jbc@jbcsystems.com
http://www.lies.com/jbc/