Czy skrypty Perla naprawdę nie powinny mieć rozszerzenia?

Właśnie zacząłem czytać O'Reilly's Learning Perl, 6. edycja i byłem zaskoczony, gdy natknąłem się na ten fragment.

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

Wyobraźmy sobie, że wpisałeś to w edytorze tekstu. (Nie martw się jeszcze o to, co oznaczają części i jak one działają. Za chwilę zobaczysz o nich.) Możesz ogólnie zapisać ten program pod dowolną nazwą. Perl nie wymaga żadnego specjalnego rodzaju nazwy pliku ani rozszerzenia i lepiej nie używać rozszerzenia w ogóle.

Dlaczego lepiej nie mieć rozszerzenia? Wyobraź sobie, że napisałeś program do obliczania wyników kręgli i powiedziałeś wszystkim znajomym, że nazywa się to bowling.plx. Pewnego dnia postanawiasz przepisać go w C. Czy nadal nazywasz go tym samym imieniem, co oznacza, że ​​wciąż jest napisany w Perlu? A może mówisz wszystkim, że ma nową nazwę? (I nie nazywaj to bowling.c, proszę!) Odpowiedź jest taka, że ​​to nie ich sprawa, w jakim języku jest napisany, jeśli tylko go używa. Więc powinno to być po prostu nazywane kręgle.

Jest to jedyne źródło, jakie widziałem w tym widoku, wszystko, co przeczytałem, obsługuje rozszerzenie .pl. Nie jestem jeszcze programistą Perla i chciałem wiedzieć, jaki jest pogląd społeczności na ten temat, zanim przyzwyczaiłem się.

Porady zawarte w książce są całkowicie poprawne - przynajmniej w przypadku systemów podobnych do UNIX. Wykonanie skryptu jest kontrolowane przez #!linię, a nie przez część rozszerzenia nazwy pliku. Użycie specjalnego rozszerzenia dla skryptów Perla ujawnia informacje, które nie powinny być ważne dla osób uruchamiających skrypt.

Windows to inna sprawa. Windows nie obsługuje #!mechanizmu; zamiast tego metoda zastosowana do otwarcia pliku zależy od rozszerzenia. Na przykład powłoka systemu Windows może być skonfigurowana w taki sposób, że dwukrotne kliknięcie .plpliku (lub wykonanie go z monitu) przekaże go jako argument do interpretera Perla. Zainstalowanie systemu Perl prawdopodobnie skonfiguruje to automatycznie.

W przypadku skryptów Perla, które mają być przenośne, .plsufiks wymagany przez system Windows może „przeciekać” do systemów typu UNIX. Prawdopodobnie najlepiej jest mieć metodę instalacji specyficzną dla systemu, która wybiera odpowiednią nazwę skryptu podczas instalacji.

W systemie UNIX-like układów, zastosowano .plrozszerzenie jest przeważnie nieszkodliwa, a jeśli okaże się ona przydatna jako przypomnienie tego, co język jest używany przez danego skryptu (być może masz kolekcję .pl, .py, .sh, i .rbskrypty), to może to zrobić. Istnieją jednak wady tego podejścia, jak opisano w książce: jeśli ponownie wdrożysz skrypt w innym języku, będziesz musiał zmienić nazwę i zaktualizować wszystko, co ją nazywa.

( Moduły Perla muszą mieć .pmrozszerzenie, aby Perl mógł je znaleźć. Na przykład:

use Foo::Bar;

spowoduje, że interpreter wyszuka plik o nazwie Bar.pmw katalogu o nazwie Foopod jednym z katalogów wymienionych w @INCtablicy. Ale .pmpliki nie mają być wykonywane bezpośrednio).

To jedyne źródło, jakie widziałem w tym widoku, wszystko, co przeczytałem, obsługuje .plrozszerzenie.

To mnie zaskakuje. Większość porad, które widziałem, mówi, aby nie używać .plrozszerzenia do skryptów wykonywalnych.

Nie ma znaczenia

#!/usr/bin/perl

mówi systemowi, jakiego programu użyć do uruchomienia kodu.

jeśli zmieniłeś to na

#!/usr/bin/bash

lub

#!/usr/bin/python

użyłbyś innego tłumacza.

Posiadanie rozszerzenia jest całkowicie opcjonalne, a fakt, że użytkownik nie musi znać języka, jest w 100% poprawny w większości przypadków.

bieganie add 2 3i powrót 5 to wszystko, na czym mi zależy (jako użytkownik).

Jedynie raz dodam rozszerzenie do skryptów, jeśli potrzebuję, aby użytkownik końcowy (czasami mój własny) znał język z jakiegoś powodu.

example.sh lub example.pl, aby pokazać różne sposoby wykonania tego samego zadania.

To powiedziawszy jednak, częściej nie ma rozszerzenia, ale wszystko smakuje.

Fragment rzeczywiście stanowi doskonale uzasadnioną radę.

Dodałbym również, że w przypadku mniejszego systemu dość trywialne jest przejrzenie i zmiana nazwy kilku plików i / lub ciągów znaków tu i tam w przypadku zmiany zdania na temat implementacji.

Z drugiej strony współczesny trend w tworzeniu dużych systemów wymaga posiadania głównego pliku wykonywalnego bez rozszerzenia, podczas gdy wszystkie moduły, od których zależy, nadal mają rozszerzenie specyficzne dla języka.

W rzeczywistości Python wymaga tego z założenia i zwykle główny skrypt Pythona (ten bez rozszerzenia w nazwie) to tylko kilka wierszy ładujących całą aplikację.

Książka mówi ci tylko, że w Uniksie rozszerzenie pliku jest niczym więcej niż konwencją. W rzeczywistości wiele rodzajów plików należy do tej kategorii. Pliki Ruby używają tej samej konwencji, więc nie potrzebują rozszerzenia .rb. Kompilatory C potrzebują tylko poprawnego kodu C, więc możesz nazwać je .watoozy, jeśli chcesz.

Chociaż nie ma technicznych ograniczeń, istnieje praktyczna granica zasady najmniejszego zaskoczenia . Zasadniczo byłoby bardzo zaskakujące, aby zobaczyć kod ruby ​​w pliku .pl, więc ludzie zazwyczaj tego nie robią.

Jedyny wyjątek od reguły

W niektórych aplikacjach serwerowych skrypt startowy znajduje się w pliku bez rozszerzeń, aby ułatwić uruchomienie aplikacji jako usługi. Plik wygląda jak każde inne skompilowane polecenie w tym przypadku. Tak długo, jak masz zainstalowany Perl, będzie się tak zachowywał.

Fragment książki „O'Reilly's Learning Perl, wydanie 6” to śmieci. Porównywanie C do Perla nie jest równoważne, dla starterów C będzie kompilowany do pliku binarnego, który nie ma rozszerzenia.

Perl nie będzie się kompilował, więc niektóre edytory tekstu będą potrzebowały rozszerzenia, aby zidentyfikować typ pliku.

Ponieważ oprócz najlepszej praktyki nie należy na stałe kodować pełnej nazwy pliku skryptu z rozszerzeniem w dowolnym miejscu w systemie, zawsze należy używać dowiązania symbolicznego lub aliasu zależnego od systemu operacyjnego.

W przyszłości, jeśli chcesz zmienić oryginalny plik, wystarczy zmienić dowiązanie symboliczne, aby wskazywało nową lokalizację.