Я только начал читать O'Reilly Learning Perl, 6th Edition, и был удивлен, когда наткнулся на этот отрывок.
#!/usr/bin/perl
print "Hello, world!\n";
Давайте представим, что вы ввели это в свой текстовый редактор. (Пока не беспокойтесь о том, что значат эти части и как они работают. О них вы узнаете чуть позже.) Как правило, эту программу можно сохранить под любым именем. Perl не требует никакого специального вида имени файла или расширения, и лучше вообще не использовать расширение.
Почему лучше не иметь расширения? Представьте, что вы написали программу для подсчета очков в боулинге и сказали всем своим друзьям, что она называется bowling.plx. Однажды вы решили переписать его на C. Вы все еще называете его тем же именем, подразумевая, что он все еще написан на Perl? Или вы всем говорите, что у него новое имя? (И не называйте это bowling.c, пожалуйста!) Ответ в том, что это не их дело, на каком языке они написаны, если они просто используют его. Так что, во-первых, его просто нужно было назвать боулингом.
Это единственный источник, который я видел в этом представлении, все остальное, что я прочитал, поддерживает расширение .pl. Я еще не программист на Perl, и я хотел узнать мнение сообщества по этому поводу, прежде чем я приобрел привычку.
.pl
расширение для программ, которые я хотел бы распространять (эта информация - шум, а не сигнал), но это полезное напоминание для локальных сценариев. В любом случае, это обсуждение не имеет значения для> 90% кода Perl, поскольку оно либо в модуле (.pm
требуется расширение), либо в тесте (.t
расширение обычно).#!/usr/bin/env perl
как скрипт Perl, если у файла нет конфликтующего расширения (например,.cpp
).file
Программа (используется для вывода типа MIME для данного входа) правильно выводитtext/x-perl
независимо от расширения.Ответы:
Рекомендации в книге совершенно верны - по крайней мере для UNIX-подобных систем. Выполнение скрипта контролируется
#!
строкой, а не расширением части имени файла. Использование специального расширения для сценариев Perl предоставляет информацию, которая не должна быть важной для всех, кто запускает сценарий.Окна это другое дело. Windows не поддерживает
#!
механизм; вместо этого метод, используемый для открытия файла, зависит от расширения. Например, оболочка Windows может быть настроена таким образом, что двойной щелчок по.pl
файлу (или выполнение его из приглашения) передаст его в качестве аргумента интерпретатору Perl. Установка системы Perl, вероятно, установит это для вас автоматически.Для сценариев Perl, предназначенных для переносимости,
.pl
требуемый Windows суффикс может «просочиться» в UNIX-подобные системы. Вероятно, лучше иметь системный метод установки, который выбирает подходящее имя для скрипта при его установке.В UNIX-подобные системам
.pl
расширение в основном безвредно, и если вы найдете его полезным в качестве напоминания о том , что язык используется конкретным сценарием (возможно , у вас есть коллекция.pl
,.py
,.sh
, и.rb
скриптов), то вы можете сделать это. Но у этого подхода есть недостатки, как описано в книге: если вы переопределите скрипт на другом языке, вам придется изменить имя и обновить все, что его вызывает.( Модули Perl должны иметь
.pm
расширение, чтобы Perl мог их найти. Например, это:заставит интерпретатор искать файл с именем
Bar.pm
в каталоге, указанномFoo
в одном из каталогов, перечисленных в@INC
массиве. Но.pm
файлы не предназначены для непосредственного выполнения.)Я нахожу это удивительным. В большинстве советов, которые я видел, говорится, что не следует использовать
.pl
расширение для исполняемых скриптов.источник
Не имеет значения
сообщает системе, какую программу использовать для запуска кода.
если вы изменили это на
или
Вы бы использовали другой переводчик.
Наличие расширения является совершенно необязательным, и точка зрения о том, что пользователю не нужно знать язык, является на 100% правильной в большинстве случаев.
бег
add 2 3
и возвращение 5 - это все, о чем я забочусь (как пользователь).Единственный раз, когда я добавляю расширение к сценариям, это если мне нужно, чтобы конечный пользователь (иногда сам) знал язык по какой-то причине.
example.sh или example.pl, чтобы показать различным способам выполнения одной и той же задачи.
Все, что сказано, хотя, более распространено, чтобы не иметь расширение, но это все вкус.
источник
Отрывок действительно дает совершенно правильный совет.
Я также добавил бы, что для небольшой системы довольно просто перебрать и переименовать несколько файлов и / или строк здесь и там в случае изменения вашего мнения о реализации.
С другой стороны, современная тенденция в разработке больших систем предполагает наличие основного исполняемого файла без каких-либо расширений, в то время как все модули, от которых он зависит, все еще имеют расширение для конкретного языка.
Фактически, Python требует этого по своему замыслу, и обычно основной скрипт Python (без расширения в имени) - это всего лишь несколько строк, загружающих все приложение.
источник
Все, что говорит вам книга, это то, что в Unix расширение файла - не более чем соглашение. На самом деле, многие типы файлов попадают в эту категорию. В файлах Ruby используется то же соглашение, поэтому им не нужно расширение .rb. Компиляторам C нужен только действительный код C, поэтому вы можете назвать их .watoozy, если хотите.
Хотя нет технических ограничений, существует практическое ограничение принципа наименьшего удивления . По сути, было бы очень удивительно видеть код ruby в файле .pl, поэтому люди обычно этого не делают.
Единственное исключение из правила
В некоторых серверных приложениях сценарий запуска находится в файле без расширения, чтобы упростить запуск приложения в качестве службы. В этом случае файл выглядит как любая другая скомпилированная команда. Пока у вас установлен Perl, он будет вести себя так же.
источник
.
как исходный код С,.cpp
,.cc
,.C
как исходный код C ++,.o
а объектный файл будет передан линкера, и так далее. Вы можете переопределить это с помощью параметра командной строки, но я использовал его так редко, что не помню, что это такое..c
Расширение для исходных файлов C имеет важное значение..pl
Расширение для исполняемых скриптов на Perl не является (по крайней мере , на UNIX-подобных системах).c99
команды: pubs.opengroup.org/onlinepubs/9699919799/utilities/…Отрывок из книги "O'Reilly's Learning Perl, 6th Edition" - мусор. Сравнение C с Perl не эквивалентно, для начала C будет скомпилирован в двоичный файл, который не имеет расширения.
Perl не будет компилироваться, поэтому некоторым текстовым редакторам понадобится расширение для определения типа файла.
В дополнение к рекомендациям, вам не следует жестко задавать полное имя файла сценария с расширением где-либо в вашей системе. Вы всегда должны использовать символическую ссылку, или псевдоним зависит от вашей операционной системы.
В будущем, если вам нужно изменить исходный файл, вам нужно всего лишь изменить символическую ссылку, чтобы указать ваше новое местоположение.
источник
#!
). Вы упомянули, что работаете над linux, и это здорово .. В следующий раз, когда вы устанавливаете приложение с менеджером пакетов, обратите пристальное внимание на то, как оно создает символическая ссылка на ваш каталог bin вместо того, чтобы просто записывать файл прямо в вашbin
каталог ... каждый удивляется почему./usr/bin
, а не как символические ссылки; все они были установлены менеджером пакетов системы. Менеджер пакетов имеет собственную базу данных, которая отслеживает расположение всех файлов для каждого пакета. (Для программного обеспечения, которое я создаю из исходного кода, я использую символические ссылки.) Но я не уверен, что это имеет отношение к тому, должно ли сценарии Perl иметь.pl
расширение.