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.plbut
"What is that?... From the 1900's? Like nobody does that anymore."Alternatively, you could begin a perl script with the following:
- Cliff Pantone, "Bring It On"
#!/usr/bin/perlWhen 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.plThere 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.
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 -*-
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.
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