我正在查看我的 CPAN 发行版，并意识到我的 .t 脚本顶部有各种不一致的东西，这取决于我从哪里下载它们。这当然得罪了我。
那么，Perl 测试 (.t) 脚本的“最佳”第一行是什么？对我的 .cpanm 资源的一项非科学调查显示：
3429 use strict;
3211 #!/usr/bin/perl
1344 #!/usr/bin/env perl
937 #!perl
909 #!/usr/bin/perl -w
801 #!perl -w
596
539 #!perl -T
与我应该为 Perl 脚本的 shebang 行使用什么相关？，但在这里我想知道shebang是否有必要/有用，如果总是期望从证明中调用测试。
use strict;应该在每个 Perl 程序中（以及use warnings;可能还有一些其他程序（取决于您与谁交谈）。它不必是第一行。
您提供的其余内容只是shebang的多个版本。在 Unix 和基于 Unix 的系统上，shebang用于告诉解释器使用。如果shebang不存在，则将使用当前 shell。（也就是说，如果你的 shell 支持shebang 1。）。
如果您在 Windows 系统上，则该shebang行是无用的。Windows 使用文件的后缀来确定如何执行文件。
问题是您是否真的需要在通过测试工具运行的脚本中添加一个shebang行。我通常不会单独执行这些测试脚本，因此可能根本不需要 shebang。在极少数情况下您确实想要执行这些脚本之一，您始终可以将它们作为perl命令本身的参数运行。Perl 模块也是如此。
那么，为什么是shebang？主要是习惯。我也在我的测试脚本和模块上放了一个。如果没有别的，它可以很容易地独立运行模块和测试脚本以进行测试。另外，shebang让人们知道这是一个 Perl 脚本，而不是 shell 脚本或 Python 脚本。
不过，shebang 有一个小问题，这与便携性有关。如果我放在#! /usr/bin/perl第一行，并且 Perl 解释器在 中#! /usr/local/bin/perl，我会得到一个错误。因此，许多shebang反映了该开发人员的 Perl 解释器的位置。
还有另一个问题：我使用Perlbrew，它允许我安装多个版本的 Perl。我目前在我的 shell 中拥有的 Perl 版本是/Users/David/perl5/perlbrew/perls/perl-5.18.0/bin/perl. 如果我将该程序传递给另一个系统上的另一个用户，那就不好了。或者，如果我决定要在 5.10 下测试我的 Perl 脚本。
该#! perl变体试图解决这个问题。在 SunOS（我相信）上，这将执行您的 Perl $PATH（因为它可能是/usr/local/bin/perl或/usr/share/bin/perl取决于/usr/bin/perl系统）。但是，这不适用于大多数 Unix 机器。例如，在我的 Mac 上，我会收到一个错误的解释器错误。
我用#! /usr/bin/env perl. 该env程序接受参数perl，查看perlmy 上的位置$PATH，然后执行 Perl 恰好在我的 $PATH 上的任何位置的完整路径。这是最通用的shebang方式，也是我推荐的方式。它允许用户毫无问题地使用 Perlbrew。
注意，我说的是几乎普遍，而不是普遍。在几乎所有系统上，env都位于 中/usr/bin，但显然有些系统位于env上/bin、位于其他位置或根本不在系统上。
执行-wPerl 时打开警告。在 Perl 5.6 之前，您使用它来打开警告。在 Perl 5.6 之后，您可以使用更灵活use warnings;且-w现在被认为已弃用的2。程序可能会使用它，因为它们最初是在 5.6 之前编写的，从未修改过，或者开发人员只是出于习惯这样做。
与污染模式-T有关。污点模式通常用于 CGI 脚本。基本上，在污染模式下，来自程序外部的数据被认为是污染的，并且在未污染之前不能使用。污点模式也会影响和。@INCPERLLIB
真正的答案是没有固定的答案。出于习惯，我会将#! /usr/bin/env perl第一行作为我的第一行——即使我从未期望从 Unix 命令行执行该文件。对于几乎总是作为安装的一部分而不是直接从命令行执行的这些类型的脚本，实际上不需要它。您所看到的实际上是 30 年 Perl 习惯和杂乱无章的结果。
1.你的 shell 支持shebang，除非你使用的是 30 年前的 Bourne shell 版本或非常旧的 C shell 版本。
2.我其实不知道-w有没有被官方弃用，但没有理由使用它。
.t文件仍然是常规的 Perl 脚本。在第一行使用此特定脚本所需的任何内容。