DISCLAIMER: THESE PAGES ARE STILL UNDER CONSTRUCTION. NO CODE EXAMPLE BEEN TESTED YET.

Introduction to Perl

Running Perl - running the examples on this site


[Previous Page] |[Next Page] Table of Contents: small | med | large

How to run a Perl script [back to top]

I'm going to assume you're working on a UNIX or Linux workstation here. Mainly because I have no idea how an NT box works.

You can run a perl script by doing the following:

	% perl myPerlScript.pl
but
"What is that?... From the 1900's? Like nobody does that anymore."
- Cliff Pantone, "Bring It On"
Alternatively, you could begin a perl script with the following:
	#!/usr/bin/perl
When the UNIX kernel looks at your script and sees that as the first line, it sees #! and invokes /usr/bin/perl and treats the entire file as a perl script. If you have a program named myPerlScript.pl that begins with that line (and you modify the permissions to make it execuatable), then you can run your program directly from the UNIX prompt:
	% myPerlScript.pl
There are some weaknesses with this approach. Though it will generally work on most UNIX boxes, you are not guaranteed that perl resides in /usr/bin. Programming Perl [WALL00] describes an alternative first couple lines:
  1 #!/bin/sh -- # -*- perl -*-
  2 eval 'exec perl $0 ${1+"$@"} ;'
  3   if 0;

Listing 2.2.1 for code_untested/shHeader-0.pl

Now, What this does is start off with /bin/sh. Though we may be unsure of the location of perl, we do have a lot of confidence that /bin/sh exists. (You're just going to have to accept that on faith.) This lets /bin/sh handle the script. With the exec, it passes control of the script to perl. Perl looks at the script, and sees that the first line contains the word "perl," so it interprets the rest as a perl script. Plus it has a little extra stuff in there to let emacs know that we really have a Perl script even though we said /bin/sh, so it will turn on Perl context highlighting if you have it.

As long as Perl is in your path, then the exec perl will hand off control to the first perl it finds in your path. This may or may not be desirable. At JPL, this seemed like a reasonable approach.

In production, you often may want more control than that. For example, you might want to hold the location of the desired Perl in an environment variable like PERLLOCATION. (Don't worry too much about this part. Your sysadmin has probably already set this up.) But we can modify our opening line to be:

  1 #!/bin/sh -- # -*- perl -*-
  2 eval 'exec $PERLLOCATION/bin/perl $0 ${1+"$@"} ;'
  3   if 0;

Listing 2.2.2 for code_untested/shHeader-1.pl

This will let you set PERLLOCATION to something like /usr. Your sysadmin may set a location like this for you, and you should ask them if there is an environment variable to do this... One way that this may be used is if your facility keeps multiple versions of Perl. Perhaps there is a custom dynamic library you are including, or maybe you are beta testing a new less-than-stable version of Perl. But you will be able to use the environment variable PERLLOCATION to pick which one.

But there is a problem here. This works just fine on IRIX (SGI), and I think it works on SunOs/Solaris and HPUX as well. But it won't work on Linux. Paul D. Smith pointed out to me that if you run the same sh command directly from the shell (instead of through #! in a script), then it actually works with no error. Paul informs me that Linux does not properly parse that first line if it begins with #!. Instead of getting all of the arguments, it assumes that anything after the /bin/sh is a single argument.


How to really Invoke Perl (Linux friendly) [back to top]

There are two common ways of starting up a perl script in UNIX. I've gone over the common sh way to do it, and there is an equivalent csh way to do it that also fails on Linux. Doug "Coop" Cooper and I came up with the following:

  1 #!/bin/sh
  2 #! -*- perl -*-
  3 eval 'exec $PERLLOCATION/bin/perl -x -S $0 ${1+"$@"} ;'
  4   if 0;

Listing 2.2.3 for code_untested/shHeader.pl

In case you're interested in what that all means (though you really don't need to know this; you can just trust me that it works): if an emacs user tries to open up the code, emacs(xemacs anyway) would usually see the sh and assume that we are editing a sh or csh file, and it will set color preferences accordingly. As a courtesy to our emacs users, we insert the string -*- perl -*- somewhere in the first 2 lines, which is a flag to emacs that this is perl code. Well, sh and csh don't like strings like that, so we avoid putting them on the first line.

However, Perl will choke if it doesn't see the string perl on the first line... unless you're invoking perl with the -x flag, which tells it that there is a lot of trash at the beginning of the file, and that it should really start parsing on the first line that it sees that starts with #! and has the string perl somewhere on that line.

I should probably mention that some people like to do this with csh. In Linux, you only have tcsh, not csh, and you run into the same problems that bash had. Fortunately, the same trick works here:

  1 #!/bin/csh -f
  2 #! -*- perl -*-
  3 eval 'exec $PERLLOCATION/bin/perl -x -S $0 $*:q'
  4   if 0;

Listing 2.2.4 for code_untested/cshHeader.pl

Personally, I follow the O'Reilly party line that csh is evil, so I prefer the sh beginning.

Now, I should mention that sh is supposed to be a Bourne shell, but these days, it usually doesn't anymore. IRIX 6.4 or higher has moved on to making it a ksh(Korn shell), which I don't really know much about, but it looks and feels pretty similar to Bourne shell. As mentioned earlier, on a Linux system, sh means bash (Bourne Again SHell). To complicate things, on a Macintosh OS-X system, sh really means zsh. I really haven't had any experience with zsh, except to know that it breaks because it doesn't preserve spaces inside command line arguments.

In short, sh, while generally a good thing, can be unreliable if you're trying to develop a single script that will work across several platforms (actually only Macintosh OS-X seems to break it). Fortunately, Korn shell (ksh) seems to be pretty reliable:

  1 #!/bin/ksh
  2 #! -*- perl -*-
  3 eval 'exec $PERLLOCATION/bin/perl -x -S $0 ${1+"$@"} ;'
  4   if 0;

Listing 2.2.5 for code_untested/kshHeader.pl
(Though I have heard rumors that ksh has problems in AIX, but I haven't verified that, so I don't know if that is still the case.)

Currently, it is my recommendation to use the sh way, unless you're on OS-X, then you should probably take ksh. My distribution of RedHat didn't have ksh. Otherwise I would recommend ksh.


Running the examples on this site [back to top]

I have tried to use the above invocation in most of the examples on this site. If you download an example and want to run it, change the permissions to make the script executable (chmod +x). As noted earlier, this way of starting the scripts allows you to control which version of perl to use through the environment variable, PERLLOCATION. this also means you must set this variable. So either add this to your .cshrc file or enter it on the UNIIX prompt:

	setenv PERLLOCATION /usr

© 2001 Steve Hwan, hostname: @pacbell.net, username: svhwan
You should probably use the word "PERL" in the subject line to get my attention.
Last Modified: Sun Dec 2 15:28:39 2001