Czy skrypty Perla naprawdę nie powinny mieć rozszerzenia?


12

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ę.


Jak wyjaśniają odpowiedzi, rozszerzenie nie jest ważne. W przypadku skryptów (w tym Perla) ważna jest linia shebang .

1
Nie proszę pana, nie zgadzam się. Bez rozszerzenia pliku, w jaki sposób edytory IDE i programiści decydują o podświetlaniu składni?
GrandmasterB

3
@GrandmasterB, patrząc na linię shebang lub czytając modeliny. Nigdy nie użyłbym .plrozszerzenia dla programów, które chciałbym rozpowszechniać (ta informacja to szum, a nie sygnał), ale jest to przydatne przypomnienie dla lokalnych skryptów. W każdym razie ta dyskusja nie ma znaczenia dla> 90% kodu Perla, ponieważ jest on albo w module ( .pmwymagane rozszerzenie), albo w teście ( .tstandardowe rozszerzenie).
amon

1
@GrandmasterB Programuję w systemie Linux i zarówno Vim, jak i Kate poprawnie identyfikują plik rozpoczynający się od wiersza #!/usr/bin/env perljako skrypt Perla, jeśli plik nie ma konfliktu rozszerzenia (np. .cpp). fileProgram (używany wywnioskować typ MIME dla danego wejścia) prawidłowo dedukuje text/x-perlniezależnie od rozszerzenia.
amon

3
Gdzieś tam myślałem, zauważyliśmy, że .pl rozszerzenie było dla p ERL l ibraries i jakoś przekształcił co ludzie wykorzystywane do programów.
brian d foy

Odpowiedzi:


14

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.


1

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.


1

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ę.


0

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ł.


Kompilatory C zwykle traktują swoje pliki wejściowe inaczej w zależności od rozszerzenia. Na przykład, traktuje gcc .jako kod źródłowy C, .cpp, .cc, .Cjak C ++ kod źródłowy, .ow postaci pliku obiektowego być przekazywane do łącznika, i tak dalej. Możesz to zmienić za pomocą opcji wiersza polecenia, ale używałem go tak rzadko, że nie pamiętam, co to jest. .cRozszerzenie dla plików źródłowych C jest bardzo ważne. .plRozszerzenie dla wykonywalnych skryptów Perl nie jest (przynajmniej w systemach UNIX-like).
Keith Thompson

1
@KeithThompson: w rzeczywistości w systemie Unix zgodnym z SUS te rozszerzenia plików są nawet częścią specyfikacji c99polecenia: pubs.opengroup.org/onlinepubs/9699919799/utilities/…
Jörg W Mittag

-4

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ę.


Oświadczenie o edytorach tekstu może być poprawne - ale zarówno emacs, jak i vim są w stanie wykryć skrypt Perla bez specjalnego rozszerzenia. Twoje twierdzenie o „najlepszych praktykach” byłoby bardziej przekonujące przy pewnym wsparciu. Ciągle instaluję skrypty Perla w moich systemach (Linux) bez rozszerzeń i nigdy nie spowodowało to problemu.
Keith Thompson

Tak, oczywiście twój skrypt będzie działał, jeśli ma hash bang ( #!) w linii, wspominasz, że pracujesz na Linuksie, co jest świetne .. przy następnej instalacji aplikacji z menedżerem pakietów zwróć szczególną uwagę na to, jak to tworzy dowiązanie symboliczne do katalogu bin zamiast po prostu zapisywać plik bezpośrednio w binkatalogu .. każdy zastanawia się dlaczego.
Aaron Goshine,

Być może zależy to od menedżera pakietów? W moim systemie Ubuntu 14.04 mam 325 skryptów Perla zainstalowanych bezpośrednio pod /usr/bin, a nie jako dowiązania symboliczne; wszystkie zostały zainstalowane przez menedżera pakietów systemu. Menedżer pakietów ma własną bazę danych, która śledzi lokalizacje wszystkich plików dla każdego pakietu. (W przypadku oprogramowania, które buduję ze źródła, używam dowiązań symbolicznych.) Ale nie jestem pewien, co to ma wspólnego z tym, czy skrypty Perla powinny mieć .plrozszerzenie.
Keith Thompson,

Wydaje mi się, że mógłbym tu znaleźć się na szczycie, chciałem o tym powiedzieć.
Aaron Goshine,

1
Czy ten komentarz miał zawierać coś więcej?
Keith Thompson,
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.