Чи справді сценарії Perl не мають розширення?

Я щойно почав читати навчальний Perl, 6-е видання O'Reilly , і здивувався, коли натрапив на цей уривок.

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

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

Чому краще не мати розширення? Уявіть, що ви написали програму для обчислення балів у боулінгу, і ви сказали всім своїм друзям, що це називається bowling.plx. Одного разу ви вирішили переписати його на C. Ви все ще називаєте його тим же ім’ям, маючи на увазі, що він все ще написаний на Perl? Або ви кажете всім, що у нього нове ім’я? (І не називайте це bowling.c, будь ласка!) Відповідь полягає в тому, що ніхто не займається їхньою справою, на якій мові написано, якщо вони просто нею користуються. Тож його треба було б назвати в першу чергу просто боулінг.

Це єдине джерело, яке я бачив із цим поглядом, все інше, що я прочитав, підтримує розширення .pl. Я ще не програміст Perl, і мені хотілося дізнатися, який погляд на це громада мала до того, як увійшла у звичку.

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

Windows - інша справа. Windows не підтримує #!механізм; натомість метод, який використовується для відкриття файлу, залежить від розширення. Наприклад, оболонка Windows може бути налаштована так, що подвійне клацання по .plфайлу (або виконання його з підказки) передасть його як аргумент інтерпретатору Perl. Встановлення системи Perl, ймовірно, встановить це автоматично для вас.

Для сценаріїв Perl, призначених для переносу, .plсуфікс, необхідний Windows, може "просочитися" на UNIX-подібні системи. Напевно, найкраще мати специфічний для системи спосіб установки, який обирає відповідне ім'я для сценарію під час його встановлення.

В UNIX-подібні системам .plрозширення в основному нешкідливо, і якщо ви знайдете його корисним в якості нагадування про те , що мова використовується конкретним сценарієм (можливо , у вас є колекція .pl, .py, .sh, і .rbскриптів), то ви можете зробити це. Але в цьому підході є недоліки, як описано в книзі: якщо ви повторно реалізуєте сценарій іншою мовою, вам доведеться змінити ім’я та оновити все, що викликає його.

( Модулі Perl повинні мати .pmрозширення, щоб Perl міг їх знайти. Наприклад, це:

use Foo::Bar;

змусить інтерпретатора шукати файл, названий Bar.pmв каталозі aa, названому 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, якщо цього хочете.

Хоча технічної стриманості немає, є практичне обмеження принципу найменшого здивування . В основному, було б дуже дивно бачити рубіновий код у файлі .pl, тому люди зазвичай цього не роблять.

Єдиний виняток із правила

У деяких серверних додатках сценарій запуску знаходиться у файлі без розширень, що спрощує запуск програми як сервісу. У цьому випадку файл виглядає як будь-яка інша складена команда. Поки у вас встановлений Perl, він буде вести себе і таким чином.

Уривок із книги "Навчання Per'l, 6-е видання" - це сміття. Порівняння C з perl не рівнозначно, для початківців C буде компілюватися у двійковий, який не має розширення.

Perl не буде компілюватися, тому деяким текстовим редакторам знадобиться розширення, щоб визначити тип файлу.

Окрім найкращої практики, ви не повинні твердо кодувати повне ім'я файлу скрипта з розширенням у будь-якій точці вашої системи, ви завжди повинні використовувати симпосилання або псевдонім залежно від вашої операційної системи.

Надалі, якщо вам потрібно змінити оригінальний файл, вам потрібно лише змінити посилання, щоб вказати на ваше нове місце.