我正在查看我的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
与What should I use for a Perl script's shebang line?相关，但在这里我想知道shebang是否必要/有用，如果总是希望从证明中调用测试。
答案 0 :(得分：2)
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，我将收到错误。因此，许多 shebangs 反映了该开发人员的Perl解释器的位置。
还有另一个问题：我使用Perlbrew允许我安装多个版本的Perl。我目前在我的shell中的Perl版本是/Users/David/perl5/perlbrew/perls/perl-5.18.0/bin/perl。如果我将该程序传递给另一个系统上的另一个用户，那就不好了。或者，如果我决定要在5.10下测试我的Perl脚本。
#! perl变体试图解决此问题。在SunOS上（我相信），这会执行$PATH中的Perl（因为它可能是/usr/local/bin/perl或/usr/share/bin/perl或/usr/bin/perl，具体取决于系统）。但是，这在大多数Unix机器上都不起作用。例如，在我的Mac上，我会得到一个错误的解释器错误。
我使用#! /usr/bin/env perl。 env程序接受参数perl，查看perl上$PATH的位置，然后执行Perl恰好位于$ PATH上的完整路径。这是执行 shebang 的最通用方式以及我推荐的方式。它允许那些使用Perlbrew而没有问题。
注意，我说几乎通用，而不是通用。在几乎所有系统上，env都位于/usr/bin，但显然有些系统env位于/bin上，位于其他地方，或者不在系统上所有
-w在执行Perl时会打开警告。在Perl 5.6之前，您使用它来打开警告。在Perl 5.6之后，您可以使用更灵活的use warnings;，-w现在被视为已弃用 2 。程序可能会使用它，因为它们最初是在5.6之前编写的，并且从未修改过，或者开发人员只是习惯性地使用它。
-T与taint mode有关。污点模式通常用于CGI脚本。基本上，在污点模式下，来自程序外部的数据被视为污染，并且在无污染之前无法使用。污点模式也会影响@INC和PERLLIB。
真正的答案是没有固定答案。我将#! /usr/bin/env perl作为习惯的第一行 - 即使我从未期望从Unix命令行执行该文件。这些类型的脚本几乎不总是作为安装的一部分执行而不是直接从命令行执行，因此不需要它。你看到的真的是30年的Perl习惯和残余的结果。
1。除非您使用的是30年前版本的Bourne shell或非常旧版本的C shell，否则您的shell支持 shebang 。
2. 我实际上不知道-w是否曾被正式弃用，但没有理由使用它。
答案 1 :(得分：-2)
.t文件仍然是常规的Perl脚本。在第一行使用此特定脚本所需的任何内容。