Perl脚本真的应该没有扩展名吗?


12

我刚开始阅读O'Reilly的《Learning Perl,第6版》,当我看到此摘录时感到惊讶。

#!/usr/bin/perl
print "Hello, world!\n";

假设您已经在文本编辑器中输入了该内容。(不必担心这些部分的含义以及它们如何工作。稍后您会看到它们的意思。)通常,您可以将该程序保存为所需的任何名称。Perl不需要任何特殊的文件名或扩展名,最好不要使用任何扩展名。

为什么没有扩展更好?想象一下,您已经编写了一个计算保龄球得分的程序,并且已经告诉所有朋友它的名称为bowling.plx。有一天,您决定用C重写它。您是否仍用相同的名称来命名它,这意味着它仍然是用Perl编写的?还是您告诉所有人它都有一个新名称?(请不要把它叫做Bowling.c!)答案是,如果他们只使用它,用什么语言写的与他们无关。因此,它首先应该只是被称为保龄球。

这是我从该视图看到的唯一资源,我阅读的所有其他内容都支持.pl扩展名。我还不是Perl程序员,所以在养成习惯之前,我想知道社区对此的看法。


正如答案所解释的,扩展名并不重要。对于脚本(包括Perl),重要的是shebang行

1
不,先生,不同意。没有文件扩展名,IDE和程序员的编辑人员如何确定语法突出显示?
GrandmasterB

3
通过查看shebang行或阅读模式行来@GrandmasterB。我永远不会.pl对要分发的程序使用扩展名(信息是杂音,而不是信号),但这对于本地脚本是一个有用的提醒。无论如何,此讨论对于> 90%的Perl代码而言都是无关紧要的,因为它是在模块中(.pm需要扩展)或在测试中(.t常规扩展)。
阿蒙(Amon)

1
@GrandmasterB我是在Linux上开发的,#!/usr/bin/env perl如果文件没有扩展名冲突(例如.cpp),则Vim和Kate都可以正确地将以该行开头的文件标识为Perl脚本。该file程序(用于推断给定输入的MIME类型)正确地推断出text/x-perl其扩展名。
阿蒙(Amon)2015年

3
某处在那里,我以为我们注意到特等扩展是为p ERL ibraries,并以某种方式演变成什么用于程序的人。
brian d foy

Answers:


14

本书中的建议是完全有效的-至少对于类似UNIX的系统而言。脚本的执行是由#!行控制的,而不是文件名的扩展部分。对Perl脚本使用特殊的扩展名可以显示对运行脚本的任何人都不重要的信息。

Windows是另一回事。Windows不支持该#!机制。而是,用于打开文件的方法取决于扩展名。例如,可能配置了Windows Shell,以便双击.pl文件(或从提示执行文件)会将其作为参数传递给Perl解释器。安装Perl系统可能会自动为您设置。

对于打算移植的Perl脚本.pl,Windows所需的后缀可能会“泄漏”到类似UNIX的系统上。最好使用特定于系统的安装方法,以便在安装脚本时为其选择合适的名称。

在类Unix系统中,.pl扩展大多是无害的,如果你发现它十分有用的是什么语言的使用由特定脚本提醒(也许你有一个集合.pl.py.sh,和.rb脚本),那么你就可以做到这一点。但是,这种方法有其缺点,如书中所述:如果用另一种语言重新实现脚本,则必须更改名称并更新调用该脚本的所有内容。

(Perl 模块需要具有.pm扩展名,以便Perl可以找到它们。例如,这:

use Foo::Bar;

将导致解释器搜索在数组中列出的目录之一下的一个Bar.pm目录中命名的文件。但是文件并不能直接执行。)Foo@INC.pm

这是我在该视图中看到的唯一资源,我阅读的所有其他内容均支持该.pl扩展。

我感到惊讶。我见过的大多数建议都说不要.pl对可执行脚本使用扩展名。


1

没关系

#!/usr/bin/perl

告诉系统使用什么程序来运行代码。

如果您将其更改为

#!/usr/bin/bash

要么

#!/usr/bin/python

您将使用其他解释器。

具有扩展名是完全可选的,并且在大多数情况下,用户不需要知道该语言的观点是100%正确的。

运行add 2 3和恢复5是我(作为用户)关心的全部。

我唯一一次向脚本添加扩展名是因为某些原因我需要最终用户(有时是我自己)知道该语言。

example.sh或example.pl展示了完成同一任务的不同方法。

尽管说了这么多,但没有扩展名更为常见,但这全都是味道。


1

摘录确实提出了完全正确的建议。

我还要补充一点,对于较小的系统,遍历并在这里和那里重命名一些文件和/或字符串是很琐碎的,以防万一您改变了对实现的看法。

另一方面,开发大型系统的现代趋势意味着拥有主要的可执行文件而没有任何扩展名,而它所依赖的所有模块仍然具有特定于语言的扩展名。

实际上,Python 是设计上要这样做的,通常主要的Python脚本(名称中没有扩展名的脚本)只是引导整个应用程序的几行。


0

这本书只告诉您,在Unix上,文件扩展名仅是一个约定。实际上,许多类型的文件都属于此类。Ruby文件使用相同的约定,因此不需要.rb扩展名。C编译器仅需要有效的C代码,因此您可以根据需要将它们命名为.watoozy。

尽管没有技术上的限制,但最小惊喜原则却有实际的限制。基本上,在.pl文件中看到ruby代码非常令人惊讶,因此人们通常不会这样做。

规则的一个例外

在某些服务器应用程序中,启动脚本位于无扩展名的文件中,以使作为服务启动应用程序更加容易。在这种情况下,该文件看起来就像任何其他编译命令一样。只要您安装了Perl,它的行为也会一样。


C编译器通常根据扩展名对输入文件进行不同的处理。例如,GCC对待.作为C源代码,.cpp.cc.C如C ++源代码,.o作为一个对象文件要在链接器通过,等等。您可以使用命令行选项来覆盖它,但是我很少使用它,以至于我不记得它是什么。.cC源文件的扩展名很重要。.pl可执行Perl脚本的扩展名不是(至少在类似UNIX的系统上)。
基思·汤普森

1
@KeithThompson:事实上,柔顺SUS-Unix系统,这些文件扩展名是说明书的的偶数部分c99命令:pubs.opengroup.org/onlinepubs/9699919799/utilities/...
约克W¯¯米塔格

-4

摘录自“ O'Reilly的Learning Perl,第6版”书。将C与perl进行比较不是等效的,因为入门C会被编译为没有扩展名的二进制文件。

Perl无法编译,因此某些文本编辑器将需要扩展名才能识别文件类型。

作为最佳实践的一部分,您不应在系统中的任何位置硬编码带有扩展名的完整脚本文件名,而应始终使用符号链接或别名,具体取决于您的操作系统。

将来,如果您需要更改原始文件,则只需更改符号链接以指向您的新位置。


关于文本编辑器的声明可能是有效的-但emacs和vim都能够检测到Perl脚本而无需特殊扩展。您对“最佳实践”的主张将在某些支持下更具说服力。我一直在没有扩展的情况下在(Linux)系统上安装Perl脚本,这从来没有造成问题。
基思·汤普森

是的,当然,如果您的脚本中有井号(#!),它将运行。您提到您在Linux上工作,这很棒。一个符号链接到您的bin目录,而不是直接将文件直接写入您的bin目录。
亚伦·戈欣

也许这取决于包管理器?在我的Ubuntu 14.04系统上,我直接在325下安装了325个Perl脚本/usr/bin,而不是符号链接。它们都由系统的程序包管理器安装。程序包管理器具有自己的数据库,该数据库跟踪每个程序包的所有文件的位置。(对于从源代码构建的软件,我确实使用了符号链接。)但是我不确定Perl脚本是否应具有.pl扩展名。
基思·汤普森

我想这里可能是最重要的。
亚伦·戈欣

1
该评论是否还有其他内容?
基思·汤普森
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.