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

12

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

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

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

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

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

Джаред
источник
Как объясняют ответы, расширение не важно. Для сценариев (включая Perl) важна строка shebang .
1
Нет, сэр, не согласен. Без расширения файла как редакторы IDE и программисты выбирают подсветку синтаксиса?
GrandmasterB
3
@GrandmasterB, глядя на линию Шебанга или читая модели. Я бы никогда не использовал .plрасширение для программ, которые я хотел бы распространять (эта информация - шум, а не сигнал), но это полезное напоминание для локальных сценариев. В любом случае, это обсуждение не имеет значения для> 90% кода Perl, поскольку оно либо в модуле ( .pmтребуется расширение), либо в тесте ( .tрасширение обычно).
Амон
1
@GrandmasterB Я занимаюсь разработкой под Linux, и Vim и Kate правильно определяют файл, начинающийся со строки, #!/usr/bin/env perlкак скрипт Perl, если у файла нет конфликтующего расширения (например, .cpp). fileПрограмма (используется для вывода типа MIME для данного входа) правильно выводит text/x-perlнезависимо от расширения.
Амон
3
Где - то там , я думал , что мы уже отмечали , что .pl расширение было для р Эрл л ibraries, и каким - то образом превратился в то , что раньше люди для программ.
Брайан Д. Фой

Ответы:

14

Рекомендации в книге совершенно верны - по крайней мере для 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расширение для исполняемых скриптов.

Кит Томпсон
источник
1

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

#!/usr/bin/perl

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

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

#!/usr/bin/bash

или

#!/usr/bin/python

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

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

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

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

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

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

coteyr
источник
1

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

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

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

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

Александр Щебликин
источник
0

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

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

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

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

Берин Лорич
источник
Компиляторы Си обычно обрабатывают свои входные файлы по-разному в зависимости от расширения. Так , например, GCC лечит .как исходный код С, .cpp, .cc, .Cкак исходный код C ++, .oа объектный файл будет передан линкера, и так далее. Вы можете переопределить это с помощью параметра командной строки, но я использовал его так редко, что не помню, что это такое. .cРасширение для исходных файлов C имеет важное значение. .plРасширение для исполняемых скриптов на Perl не является (по крайней мере , на UNIX-подобных системах).
Кит Томпсон,
1
@KeithThompson: на самом деле, в SUS-совместимой системе Unix эти расширения файлов даже являются частью спецификации для c99команды: pubs.opengroup.org/onlinepubs/9699919799/utilities/…
Йорг Миттаг
-4

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

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

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

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

Аарон Гошин
источник
Утверждение о текстовых редакторах может быть верным, но и emacs, и vim могут обнаружить скрипт Perl без специального расширения. Ваше утверждение о «лучшей практике» было бы более убедительным при некоторой поддержке. Я постоянно устанавливаю Perl-скрипты на мои (Linux) системы без расширений, и это никогда не вызывало проблем.
Кит Томпсон
Да, конечно, ваш скрипт будет работать, если в нем есть хэш bang ( #!). Вы упомянули, что работаете над linux, и это здорово .. В следующий раз, когда вы устанавливаете приложение с менеджером пакетов, обратите пристальное внимание на то, как оно создает символическая ссылка на ваш каталог bin вместо того, чтобы просто записывать файл прямо в ваш binкаталог ... каждый удивляется почему.
Аарон Гошин
Возможно, это зависит от менеджера пакетов? В моей системе Ubuntu 14.04 у меня 325 сценариев Perl, установленных непосредственно под /usr/bin, а не как символические ссылки; все они были установлены менеджером пакетов системы. Менеджер пакетов имеет собственную базу данных, которая отслеживает расположение всех файлов для каждого пакета. (Для программного обеспечения, которое я создаю из исходного кода, я использую символические ссылки.) Но я не уверен, что это имеет отношение к тому, должно ли сценарии Perl иметь .plрасширение.
Кит Томпсон
Я думаю, что, возможно, ушел с вершины здесь, точка, которую я пытался сделать, это.
Аарон Гошин
1
Должно ли быть что-то еще к этому комментарию?
Кит Томпсон