Должны ли Perl-скрипты действительно иметь расширение?

Я только начал читать O'Reilly Learning Perl, 6th Edition, и был удивлен, когда наткнулся на этот отрывок.

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

Давайте представим, что вы ввели это в свой текстовый редактор. (Пока не беспокойтесь о том, что значат эти части и как они работают. О них вы узнаете чуть позже.) Как правило, эту программу можно сохранить под любым именем. Perl не требует никакого специального вида имени файла или расширения, и лучше вообще не использовать расширение.

Почему лучше не иметь расширения? Представьте, что вы написали программу для подсчета очков в боулинге и сказали всем своим друзьям, что она называется bowling.plx. Однажды вы решили переписать его на C. Вы все еще называете его тем же именем, подразумевая, что он все еще написан на Perl? Или вы всем говорите, что у него новое имя? (И не называйте это bowling.c, пожалуйста!) Ответ в том, что это не их дело, на каком языке они написаны, если они просто используют его. Так что, во-первых, его просто нужно было назвать боулингом.

Это единственный источник, который я видел в этом представлении, все остальное, что я прочитал, поддерживает расширение .pl. Я еще не программист на Perl, и я хотел узнать мнение сообщества по этому поводу, прежде чем я приобрел привычку.

Рекомендации в книге совершенно верны - по крайней мере для UNIX-подобных систем. Выполнение скрипта контролируется #!строкой, а не расширением части имени файла. Использование специального расширения для сценариев Perl предоставляет информацию, которая не должна быть важной для всех, кто запускает сценарий.

Окна это другое дело. Windows не поддерживает #!механизм; вместо этого метод, используемый для открытия файла, зависит от расширения. Например, оболочка Windows может быть настроена таким образом, что двойной щелчок по .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расширение для исполняемых скриптов.

Не имеет значения

#!/usr/bin/perl

сообщает системе, какую программу использовать для запуска кода.

если вы изменили это на

#!/usr/bin/bash

или

#!/usr/bin/python

Вы бы использовали другой переводчик.

Наличие расширения является совершенно необязательным, и точка зрения о том, что пользователю не нужно знать язык, является на 100% правильной в большинстве случаев.

бег add 2 3и возвращение 5 - это все, о чем я забочусь (как пользователь).

Единственный раз, когда я добавляю расширение к сценариям, это если мне нужно, чтобы конечный пользователь (иногда сам) знал язык по какой-то причине.

example.sh или example.pl, чтобы показать различным способам выполнения одной и той же задачи.

Все, что сказано, хотя, более распространено, чтобы не иметь расширение, но это все вкус.

Отрывок действительно дает совершенно правильный совет.

Я также добавил бы, что для небольшой системы довольно просто перебрать и переименовать несколько файлов и / или строк здесь и там в случае изменения вашего мнения о реализации.

С другой стороны, современная тенденция в разработке больших систем предполагает наличие основного исполняемого файла без каких-либо расширений, в то время как все модули, от которых он зависит, все еще имеют расширение для конкретного языка.

Фактически, Python требует этого по своему замыслу, и обычно основной скрипт Python (без расширения в имени) - это всего лишь несколько строк, загружающих все приложение.

Все, что говорит вам книга, это то, что в Unix расширение файла - не более чем соглашение. На самом деле, многие типы файлов попадают в эту категорию. В файлах Ruby используется то же соглашение, поэтому им не нужно расширение .rb. Компиляторам C нужен только действительный код C, поэтому вы можете назвать их .watoozy, если хотите.

Хотя нет технических ограничений, существует практическое ограничение принципа наименьшего удивления . По сути, было бы очень удивительно видеть код ruby ​​в файле .pl, поэтому люди обычно этого не делают.

Единственное исключение из правила

В некоторых серверных приложениях сценарий запуска находится в файле без расширения, чтобы упростить запуск приложения в качестве службы. В этом случае файл выглядит как любая другая скомпилированная команда. Пока у вас установлен Perl, он будет вести себя так же.

Отрывок из книги "O'Reilly's Learning Perl, 6th Edition" - мусор. Сравнение C с Perl не эквивалентно, для начала C будет скомпилирован в двоичный файл, который не имеет расширения.

Perl не будет компилироваться, поэтому некоторым текстовым редакторам понадобится расширение для определения типа файла.

В дополнение к рекомендациям, вам не следует жестко задавать полное имя файла сценария с расширением где-либо в вашей системе. Вы всегда должны использовать символическую ссылку, или псевдоним зависит от вашей операционной системы.

В будущем, если вам нужно изменить исходный файл, вам нужно всего лишь изменить символическую ссылку, чтобы указать ваше новое местоположение.