use strict; should be in EVERY Perl program (as well as use warnings; and maybe a few others (depending on who you are talking to). This is not the first line.
The rest of the material you submit is just a few versions of shebang . On Unix and Unix based systems, shebang is used to tell the interpreter to use. If shebang does not exist, the current shell will be used. (That is, if your shell supports shebang 1. ).
If you are on a Windows system, this shebang line is useless. Windows uses the file suffix to figure out how to execute the file.
The question is whether you really need a shebang string in the scripts that you use through the test bundle. I usually do not run these test scripts separately, so there may not be a need for a shebang at all. In the rare case you want to run one of these scripts, you can always run them as an argument to the perl command itself. The same thing happens with Perl modules.
So why shebang? Mostly a habit. I also put it on my test scripts and on my modules. If nothing else, this makes it easy to run modules and test scripts independently for testing purposes. In addition, shebang allows people to understand that it is a Perl script, not a shell script or Python script.
There's a bit of a problem with shebang, and this is related to portability. If I put the #! /usr/bin/perl #! /usr/bin/perl to its first line, and the Perl interpreter is in #! /usr/local/bin/perl #! /usr/local/bin/perl , I will get an error. Thus, many of the shebangs reflect the location of the Perl interpreter for this developer.
There is another problem: I use Perlbrew , which allows me to install multiple versions of Perl. The version of Perl that I currently have in my shell is in /Users/David/perl5/perlbrew/perls/perl-5.18.0/bin/perl . This is not good if I transfer this program to another user on another system. Or, if I decided that I want to test my Perl script under 5.10.
Option #! perl #! perl is an attempt to solve this problem. On SunOS (I suppose) this will do Perl, which is in your $PATH (since it could be /usr/local/bin/perl or /usr/share/bin/perl or /usr/bin/perl depending on the system) . However, this does not work on most Unix blocks. For example, on my Mac, I would get a bad interpreter error.
I use #! /usr/bin/env perl #! /usr/bin/env perl . The program env takes an argument perl , see where perl is on my $PATH , and then performs the full path wherever Perl's on my $ PATH. This is the most versatile way to do shebang and the way I recommend it. This allows you to use Perlbrew without any problems.
Notice, I said almost universal, not universal. In almost all systems, env is located in /usr/bin , but apparently there are some systems where env is either on /bin , or located elsewhere, or is generally absent from the system.
-w enables warnings when running Perl. Prior to Perl 5.6, you used this to enable warnings. After Perl 5.6 you can use more flexible use warnings; , and -w now deprecated 2 . Programs can use it because they were originally written before 5.6 and were never changed, or the developer just did it out of habit.
-T is associated with taint mode . Taint mode is commonly used for CGI scripts. In principle, in Taint mode, data from outside the program is considered corrupted and cannot be used until it is used. Taint mode also affects @INC and PERLLIB .
The real answer is that there is no answer. I would put #! /usr/bin/env perl #! /usr/bin/env perl as the first line of a habit, even if I never expect to execute this file from a Unix command line. There is no real need for these types of scripts, which are almost always executed as part of the installation, and not directly from the command line. What you see is really the result of 30 years of Perl habits and jerks.
1. Your shell supports shebang if you are not using the 30-year-old version of the Bourne shell or the very old version of the C shell.
2. I really do not know when -w ever officially dated, but there is no reason to use it.