What should I use for a Perl script's shebang line?

Question

Which of these is better or faster to use as the shebang line for a Perl script?

#! perl

#! perl.exe

#! fullpath/perl(/perl.exe)

#! partialpath/perl(/perl.exe)

And, when using #!perl, when it works on a particular system, how do I find out in the script which perl interpreter I'm using so I can put that one into the shebang line?

---

And, if using a /path/path/perl, are * or ... allowed to be used for the folders?

Answer 1

If you have to hard code #!, use #!/usr/bin/env perl. Why? What you want is for the Perl program to run with the user's preferred Perl. That's going to be the first on in their PATH. #!perl doesn't do what I mean, it doesn't search the user's PATH, #!/usr/bin/env perl is how you pull that off. /usr/bin/env will always be there on Unix systems.

If the user is using Windows, as others have pointed out, it doesn't matter. Windows doesn't use #! it uses file extension associations. Make sure your program is called foo.pl or something and it'll work. But include the #! line anyway as some utilities and editors make use of it.

If you're shipping code, let the installer take care of it. Both MakeMaker/Makefile.PL and Module::Build/Build.PL will change your #! line to match the perl the user used to install with. They will take care of this problem for you.

If you are installing code for your own production use, you should use the full path to a particular copy of perl. Which copy of perl? One specific to your project. Does this mean you need to compile perl for every project? No, you can make a symlink. Project foo might have /usr/local/bin/fooperl point at /usr/bin/perl5.18. Use #!/usr/local/bin/fooperl. Now if you decide to upgrade perl you can do it per project by changing the symlink.

Answer 2

A Windows she-bang (deduced from the perl.exe bit) seems irrelevant since your (ahem) "shell" probably does not even parse it (correct me if I am wrong, could have been changed lately).

Some command line flags may still be picked up by Perl itself though (according to this thread).

Answer 3

1. As ChristopheD noted, I can confirm from practice (ActivePerl on XP) that the shebang line is not really necessary on Windows.

   A shebang line tells a Unix shell which interpreter to pass the script to.

   On Windows, the program to pass the script to will be determined by associations based on the extension.

2. On Unix, the third option (full path to perl executable) is best.

   And yes, you can use ".." in theory (shell doesn't care) but you should not really use relative path - you never know what your current working directory when executing a script will be.

Answer 4

If you are running CGI via Apache on Windows, the SHEBANG IS USED. You will need the fullpath to perl.

Answer 5

If you're developing in Unix using Perl and you use "perlbrew" to easily switch between different versions of Perl, then the "!#/usr/bin/env perl" shebang line works well.

Answer 6

The first line stands for shebang. It basically tells the program where Perl interpreter is located since Perl is interpreted language. On Linux you can type in terminal:

whereis perl

which will give you exact location of it. Usually it's inside /usr/bin/perl. This means that you want to make shebang regarding to /usr/bin/perl

#! /usr/bin/perl

use strict;
use warnings;
use v5.10.1;
.
.
.

This is just some good practice, hence it's obviously fastest solution.

I hope you find this useful,

Thanks.

Answer 7

And, when using "#! perl", when it works on a particular system, what is the print() for showing the full path to perl.exe, that could be included into the Shebang Line ?

Well, if you're using the print statement you are already executing perl code, so...

Answer 8

This is one of the things which I dislike about Perl.

On Windows, if you are using ActiveState Perl at least, if the file ends with .pl then the Windows registry will run the Perl interpreter for you, regardless of the shebang line. On Cygwin, I am not sure why but #! perl works too. On Unix you should put the full path to your Perl executable in the shebang line. Schwern's idea of using env is convenient, but has some danger, as I pointed out in a comment.

This is why I suggest to you that the best solution is to package your Perl scripts as CPAN modules. CPAN installers like Module::Build will then change the shebang line to the full path to your Perl interpreter. (I am not sure whether Schwern's installer, ExtUtils::MakeMaker, does this or uses env, since I don't use it.)