Previous Section | Table of Contents | Next Section

Running "Hello, world!" from the command

line
This section of the tutorial covers:
Logging in
Checking for perl
Writing scripts on your PC vs. writing them on the Unix server
Writing the "Hello, world!" script
The "dotslash" thing
File permissions
Running the script
Logging in
The first thing you need to do is log into a Unix shell session. If you already know how to do that, great.
Otherwise:
1. Make sure your Internet service provider (hereafter "ISP") gives you a shell account as part of your
access package. If not, get another ISP.
2. Download and install a decent telnet program. (There's one that comes bundled with Windows 95; just
hit "Start:Run..." and type "telnet" (optionally putting a space and a hostname after it) in the dialog box
to start it up. My recommendation, though, is to go to TUCOWS and download something better. I've
had fairly good luck with a program called CRT, for example.)
3. Use your telnet program to log into your shell account. You'll need to know three things in order to do
this: the hostname of the computer you're logging into, your username, and your password. Your ISP
should have provided you with this information when you signed up for the account; if not, go bug them
until they give it to you.
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.
Return to the top of the page
Checking for Perl
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.)
Return to the top of the page
Writing scripts on your PC vs. writing them on the Unix server
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.
Return to the top of the page
Writing the "Hello, world!" script
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.
Return to the top of the page
The "dotslash" thing
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.
Return to the top of the page
Unix file permissions
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.
Return to the top of the page
Running the script
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.
Return to the top of the page
Previous Section | Table of Contents | Next Section
John Callender
[email protected]
http://www.lies.com/jbc/