Ich habe gerade angefangen, O'Reillys Learning Perl, 6. Ausgabe, zu lesen und war überrascht, als ich auf diesen Auszug stieß.
#!/usr/bin/perl
print "Hello, world!\n";
Stellen Sie sich vor, Sie haben das in Ihren Texteditor eingegeben. (Machen Sie sich noch keine Gedanken darüber, was die Teile bedeuten und wie sie funktionieren. Sie werden sie gleich sehen.) Sie können dieses Programm im Allgemeinen unter einem beliebigen Namen speichern. Perl benötigt keine spezielle Art von Dateinamen oder Erweiterung, und es ist besser, überhaupt keine Erweiterung zu verwenden.
Warum ist es besser, keine Verlängerung zu haben? Stellen Sie sich vor, Sie haben ein Programm zur Berechnung der Bowling-Ergebnisse geschrieben und allen Ihren Freunden gesagt, dass es bowling.plx heißt. Eines Tages beschließen Sie, es in C umzuschreiben. Nennen Sie es immer noch mit demselben Namen, was bedeutet, dass es immer noch in Perl geschrieben ist? Oder sagst du allen, dass es einen neuen Namen hat? (Und nennen Sie es bitte nicht bowling.c!) Die Antwort ist, dass es sie nichts angeht, in welcher Sprache es geschrieben ist, wenn sie es nur verwenden. Es hätte also eigentlich einfach Bowling heißen sollen.
Dies ist die einzige Quelle, die ich mit dieser Ansicht gesehen habe. Alles andere, was ich gelesen habe, hat die Erweiterung .pl unterstützt. Ich bin noch kein Perl-Programmierer und wollte wissen, wie die Community dazu steht, bevor ich mich daran gewöhnt habe.
.pl
Erweiterung für Programme verwenden, die ich verteilen möchte (diese Informationen sind Rauschen, kein Signal), aber es ist eine nützliche Erinnerung für lokale Skripte. Auf jeden Fall ist diese Diskussion für> 90% des Perl-Codes irrelevant, da sie entweder in einem Modul (.pm
Erweiterung erforderlich) oder in einem Test (.t
Erweiterung üblich) enthalten ist.#!/usr/bin/env perl
als Perl-Skript, wenn die Datei keine widersprüchliche Erweiterung hat (z. B..cpp
). Dasfile
Programm (das zum Ableiten eines MIME-Typs für eine bestimmte Eingabe verwendet wird) leitettext/x-perl
unabhängig von der Erweiterung korrekt ab .Antworten:
Der Rat in diesem Buch ist absolut gültig - zumindest für UNIX-ähnliche Systeme. Die Ausführung des Skripts wird durch die
#!
Zeile gesteuert , nicht durch den Erweiterungsteil des Dateinamens. Durch die Verwendung einer speziellen Erweiterung für Perl-Skripte werden Informationen angezeigt, die für niemanden, der das Skript ausführt, wichtig sein sollten.Windows ist eine andere Sache. Windows unterstützt den
#!
Mechanismus nicht. Stattdessen hängt die Methode zum Öffnen einer Datei von der Erweiterung ab. Beispielsweise kann die Windows-Shell so konfiguriert sein, dass ein Doppelklick auf eine.pl
Datei (oder das Ausführen an einer Eingabeaufforderung) sie als Argument an den Perl-Interpreter übergibt. Durch die Installation eines Perl-Systems wird dies wahrscheinlich automatisch für Sie eingerichtet.Bei Perl-Skripten, die portabel sein sollen, kann das
.pl
von Windows erforderliche Suffix auf UNIX-ähnliche Systeme "gelangen". Es ist wahrscheinlich am besten, eine systemspezifische Installationsmethode zu haben, die bei der Installation einen geeigneten Namen für das Skript auswählt.Auf UNIX-ähnlichen Systemen eine
.pl
ist Erweiterung meist harmlos, und wenn Sie es nützlich , als Erinnerung an das finden , was Sprache , die von einem bestimmten Skript verwendet wird (vielleicht haben Sie eine Sammlung von.pl
,.py
,.sh
und.rb
Scripts), dann können Sie das tun. Dieser Ansatz weist jedoch Nachteile auf, wie im Buch beschrieben: Wenn Sie ein Skript in einer anderen Sprache erneut implementieren, müssen Sie den Namen ändern und alles aktualisieren, was es aufruft.(Perl- Module müssen eine
.pm
Erweiterung haben, damit Perl sie finden kann. Beispiel:Der Interpreter sucht nach einer Datei
Bar.pm
in einem Verzeichnis, dasFoo
unter einem der im@INC
Array aufgeführten Verzeichnisse benannt ist . Aber.pm
Dateien sind nicht dazu gedacht , direkt ausgeführt werden.)Das finde ich überraschend. Die meisten der Rat , den ich gesehen habe , sagt nicht die verwenden
.pl
Erweiterung für ausführbare Skripte.quelle
Ist egal
teilt dem System mit, welches Programm zum Ausführen des Codes verwendet werden soll.
wenn du das geändert hast
oder
Sie würden einen anderen Interpreter verwenden.
Die Erweiterung ist völlig optional, und der Punkt, an dem der Benutzer die Sprache nicht kennen muss, ist in den meisten Fällen zu 100% korrekt.
Laufen
add 2 3
und zurückkommen 5 ist alles, was mich interessiert (als Benutzer).Das einzige Mal, wenn ich Skripten eine Erweiterung hinzufüge, ist, wenn der Endbenutzer (manchmal ich selbst) die Sprache aus irgendeinem Grund kennen muss.
example.sh oder example.pl, um verschiedene Möglichkeiten zur Ausführung derselben Aufgabe aufzuzeigen.
Trotzdem ist es üblicher, keine Erweiterung zu haben, aber es ist alles Geschmack.
quelle
Der Auszug gibt in der Tat einen vollkommen gültigen Rat.
Ich möchte auch hinzufügen, dass es für ein kleineres System ziemlich trivial ist, hier und da einige Dateien und / oder Zeichenfolgen umzubenennen, falls Sie Ihre Meinung über die Implementierung ändern sollten.
Andererseits impliziert ein moderner Trend bei der Entwicklung größerer Systeme, dass die ausführbare Hauptdatei ohne Erweiterung vorhanden ist, während alle Module, von denen es abhängt, weiterhin die sprachspezifische Erweiterung haben.
Tatsächlich erfordert Python dies von Natur aus, und normalerweise besteht das Haupt-Python-Skript (das ohne Erweiterung im Namen) nur aus wenigen Zeilen, die die gesamte App booten.
quelle
Das Buch sagt Ihnen nur, dass die Dateierweiterung unter Unix nichts anderes als eine Konvention ist. In der Realität fallen viele Dateitypen in diese Kategorie. Ruby-Dateien verwenden dieselbe Konvention, sodass sie die Erweiterung .rb nicht benötigen. C-Compiler benötigen nur einen gültigen C-Code, sodass Sie sie .watoozy nennen können, wenn Sie möchten.
Während es keine technische Einschränkung gibt, gibt es die praktische Einschränkung des Prinzips der geringsten Überraschung . Grundsätzlich wäre es sehr überraschend, Ruby-Code in einer .pl-Datei zu sehen, also machen die Leute das im Allgemeinen nicht.
Die einzige Ausnahme von der Regel
In einigen Serveranwendungen befindet sich das Startskript in einer Datei ohne Erweiterung, um das Starten der Anwendung als Dienst zu vereinfachen. Die Datei sieht in diesem Fall wie jeder andere kompilierte Befehl aus. Solange Sie Perl installiert haben, verhält es sich auch so.
quelle
.
als C - Quellcode,.cpp
,.cc
,.C
wie C ++ Quellcode,.o
als Objektdatei werden weitergegeben an den Linker, und so weiter. Sie können dies mit einer Befehlszeilenoption überschreiben, aber ich habe sie so selten verwendet, dass ich mich nicht daran erinnere, was es ist. Die.c
Erweiterung für C-Quelldateien ist wichtig. Die.pl
Erweiterung für ausführbare Perl-Skripte ist nicht (zumindest auf UNIX-ähnlichen Systemen).c99
Befehl: pubs.opengroup.org/onlinepubs/9699919799/utilities/…Der Auszug aus dem Buch "O'Reillys Learning Perl, 6. Auflage" ist Müll. Der Vergleich von C mit Perl ist nicht äquivalent. Für den Anfang wird C zu einer Binärdatei kompiliert, die keine Erweiterung hat.
Perl wird nicht kompiliert, daher benötigen einige Texteditoren die Erweiterung, um den Dateityp zu identifizieren.
Abgesehen von bewährten Methoden sollten Sie den vollständigen Skriptdateinamen mit der Erweiterung an keiner Stelle in Ihrem System fest codieren. Sie sollten immer einen Symlink oder einen Alias verwenden, der von Ihrem Betriebssystem abhängt.
Wenn Sie in Zukunft die Originaldatei ändern müssen, müssen Sie nur den Symlink ändern, um auf Ihren neuen Speicherort zu verweisen.
quelle
#!
) in der Zeile steht. Sie erwähnen, dass Sie unter Linux arbeiten, was großartig ist. Wenn Sie das nächste Mal eine Anwendung mit einem Paketmanager installieren, achten Sie genau darauf, wie sie auch erstellt wird Ein Symlink zu Ihrem bin-Verzeichnis, anstatt nur die Datei direkt in Ihrbin
Verzeichnis zu schreiben . Jedes Wunder, warum./usr/bin
, nicht als Symlinks. Sie wurden alle vom Paketmanager des Systems installiert. Der Paketmanager verfügt über eine eigene Datenbank, in der die Speicherorte aller Dateien für jedes Paket erfasst werden. (Für Software, die ich aus dem Quellcode erstelle, verwende ich Symlinks.) Ich bin mir jedoch nicht sicher, was dies damit zu tun hat, ob Perl-Skripte eine.pl
Erweiterung haben sollen.