Dateierweiterungen für Unix-Shell-Skripte [geschlossen]

45

Auf Wikipedia heißt es im Artikel für .sh :

Informationen zum Typ der .sh-Dateierweiterung finden Sie unter Bourne-Shell .

Wie wäre es mit anderen Unix-Shells?

Ich weiß , dass der shebang verwendet wird in der Datei einen Interpreter zur Ausführung , um anzuzeigen, aber ich frage mich:

Was sind die Vor- und Nachteile von Dateierweiterungen gegenüber nicht vorhandenen Dateierweiterungen?

— Amelio Vazquez-Reina
quelle

4

Manchmal können Shell-Skripte ohne shebang (oder ohne exec-Berechtigungen) gefunden werden. In diesem Fall kann ein Name mit der Endung .sh ein Hinweis für den Benutzer sein, mit dem er sie ausführen soll bash script.sh(oder shnatürlich).

— Ansgar Esztermann

3

Wenn ein Shell-Skript eine Erweiterung hat, ist dies normalerweise .sh. Ich habe noch nie ein .ksh- oder .bash-Skript gesehen. Die meisten Shell-Skripte haben jedoch keine Erweiterung, wie beispielsweise alle Skripte in /etc/init.d/*.

— Richard Holloway

Während eine vereinfachende Schlussfolgerung (ja oder nein) die Meinung ist, sind die zu berücksichtigenden Dinge nicht.

— ctrl-alt-delor

35

Ich würde nur rufen .shetwas , das ist gemeint tragbar zu sein (und hoffentlich ist tragbar).

Ansonsten finde ich es einfach besser die Sprache zu verstecken. Der aufmerksame Leser wird es ohnehin in der Shebang-Zeile finden. (In der Praxis werden Suffixe .bashoder .zshusw. nur selten verwendet.)

— Stéphane Gimenez
quelle

1

Allein von dieser Seite aus können wir bereits eine nicht unerhebliche Anzahl von Nutzern sehen. Warum sagen Sie, dass sie "selten verwendet" werden? Irgendwelche Zitate? Oder basiert dies nur auf Ihren Erfahrungen?

— Pacerier

23

Ich würde sagen, dass es aus technischen Gründen keine "guten Praktiken" für Dateierweiterungen gibt: Unix / Linux / * BSD-Dateisysteme unterstützen keine Erweiterungen an sich. Was Sie eine Erweiterung nennen, ist lediglich ein Suffix eines einzelnen Dateinamens. Das ist anders als bei den Dateisystemen und Betriebssystemen VM / CMS, VMS, MS-DOS und Windows, bei denen eine spezielle Stelle in der Inode-Moral-Entsprechung für eine Erweiterung reserviert ist.

Ich finde es ein bisschen albern, das Suffix ".sh" oder ".ksh" oder ".bash" auf den Namen einer Shell-Skriptdatei zu setzen. Ein Programm ist ein Programm: Es gibt keinen Vorteil, zu unterscheiden, was ausgeführt wird. Kein Unix- oder Linux-Kernel oder was auch immer hat beschlossen, einen Interpreter für eine Datei aufzurufen, nur wegen eines Dateinamensuffix. Es wird alles durch die #!Zeile oder eine andere "magische Zahl" -Sequenz von Bytes am Anfang der Datei erledigt . Die Entscheidung, was basierend auf einer Dateinamenerweiterung ausgeführt werden soll, ist einer der Faktoren, die Windows zu einem Malware-Magneten machen. Sehen Sie sich an, wie viele Windows-Malware-Betrugsfälle eine Datei mit dem Namen "something.jpg.exe" enthalten. In neueren Windows-Versionen wird standardmäßig die Erweiterung ".exe" nicht angezeigt.

Was Sie vielleicht für einen Direktbefehl halten, ist sowieso oft ein Shell-Skript. Manchmal ccwar es ein Sh-Skript, firefoxist ein Sh-Skript, startxist ein Sh-Skript. Ich glaube nicht, dass es einen kognitiven oder organisatorischen Vorteil hat, ein Skript mit dem Suffix ".sh" zu kennzeichnen.

— Bruce Ediger
quelle

24

Ich stimme dir nicht zu! Meine Aufgabe besteht darin, eine Anwendung zu packen, die Tausende von Dateien umfasst, von binären ausführbaren Dateien bis hin zu Shell-Skripten (ksh, bash und einige ältere csh). Glauben Sie mir, es macht einen Unterschied, auf einen Blick (oder in einem regulären Ausdruck) zu wissen, welche Art von Datei wir diskutieren und nach welcher wir suchen. Mein Punkt ist, dass es von Vorteil sein könnte, zu unterscheiden, was herausgearbeitet wird, und eine bewährte Methode sollte dazu anregen , den Dateityp explizit anzugeben .

— Rahmu

4

@rahmu: schreib das als antwort auf. Geben Sie einige Details dazu an, wie Sie mithilfe von durch Regex unterscheidbaren Namen diese Anwendung verpacken (und möglicherweise warten) können. Beachten Sie insbesondere die Wechselwirkung zwischen der Interpretation der Datei und dem Suffix des Dateinamens und wie Sie auf diese Weise Aufgaben ausführen können. Ich bin an ernsthaften Argumenten gegen meinen Standpunkt interessiert und bereit, mich zu ändern, wenn ich überzeugt bin. Ich habe Ihren Kommentar positiv bewertet, um dies zu beweisen.

— Bruce Ediger

3

Ich würde gerne, leider kann ich nur über meine aktuellen Erfahrungen in meinem aktuellen Job sprechen. Ich weiß nicht viel über bewährte Praktiken und Standards im Allgemeinen . Ich denke, ich sollte etwas recherchieren, bevor ich hier eine Antwort poste. Ich werde heute Abend nach der Arbeit

— nachsehen

2

@rahmu Der Befehl "file" dient zur Bestimmung des Dateityps. Es ist in der Lage, Skripte zu unterscheiden, die für verschiedene Shells geschrieben wurden.

— Matt

3

Wenn Sie einem Shell-Skript eine .shErweiterung geben, müssen Sie diese .shbeim Starten als Teil des Befehlsnamens eingeben. Das ist der Hauptgrund, warum ich diese Erweiterung nicht gerne einbaue (dasselbe gilt für alles, was eine Shebang-Linie hat). Übrigens ist das Problem in Windows nicht das .exePräfix an sich (es ist trivial, eine ausführbare Datei unter image.jpgLinux zu erstellen), sondern die Tatsache, dass Windows diese Erweiterung normalerweise verbirgt, kombiniert mit der Tatsache, dass die Aktion zum Starten einer ausführbaren Datei und erforderlich ist Ein Dokument zu öffnen ist genau dasselbe.

— Celtschk

12

Als einer, der in einer Vielzahl von? Nix-Umgebungen gearbeitet hat, musste ich in einer Vielzahl von Shells schreiben. Ob Sie es glauben oder nicht, über Plattformen hinweg sind die Schalen nicht gleich. Wenn Sie also Ihre persönliche Bibliothek in mehreren Shells verwalten (falls erforderlich), ist es sehr hilfreich, Erweiterungen zu verwenden, um die Shells zu identifizieren. Wenn Sie auf eine andere Plattform wechseln und die Shell etwas anders ist, wissen Sie auf diese Weise, auf welche Skripte Änderungen abzielen sollen. .sh .ksh .bsh .csh ...

— Jumpylodo
quelle

Dies scheint mit unix.stackexchange.com/questions/31760/…

— Pacerier

Haben Sie #!am Anfang des Skripts kein (z. B. #!/bin/bash)?

— Strg-Alt-Delor

Gnu / Linux, BSD und die UNIXe sind alle Unixe. Keine Notwendigkeit für? Nix. Linux ist ein Kernel, Android verwendet Linux, ist aber kein Unix (es sei denn, Sie fügen zusätzliche Software hinzu, in diesem Fall haben Sie eine Unix-App).

— Strg-Alt-Delor

@ ctrl-alt-delor: "Unix" ist eine Marke . Leute benutzen oft "? Nix", um das Markenproblem (und die Pedanten) zu vermeiden.

— JS.

@JS `UNIX 'ist eine Marke von The Open Group. Unix und Unix sind nicht greens.org/about/unix.html

— ctrl-alt-delor

5

Wie Sie sagten, sind die Unix-Dateierweiterungen reine Informationen. Sie brauchen nur Ihr Skript, um einen korrekten Shebang zu haben und ausführbar zu sein.

Sie können entweder keine Erweiterung haben oder verwenden .sh.

Ich persönlich verwende die folgenden Konventionen, unabhängig von der verwendeten Shell (csh, tcsh, bash, sh, ...):

Keine Erweiterung für System- oder High-Grade-Skripte (extrem selten).
die .shfür klassische Skripte, niedrig bis hochgradig.

— Ouki
quelle

Was meinen Sie mit "klassischen Skripten, niedrig bis hoch"?

— Pacerier

Ich denke, ich meinte damit Abstraktion oder Organisationsebene. Das heißt, es ist Ihnen egal, welche Sprache / welches Skript-Tool hinter einigen Befehlen verwendet wird: Sie verwenden also keine Erweiterung. Für andere ist es gut zu wissen, dass es sich um eine Bash oder ein exotisches ksh-Shell-Skript (mit der richtigen Erweiterung) handelt. ... aber das war vor 2 Jahren;)

— Ouki

5

Sie sollten keine Erweiterung für ausführbare Dateien verwenden, da diese nicht austauschbar sind. Stellen Sie sich vor, Sie haben ein Shell-Skript a.shund schreiben es in Python neu a.py. Jetzt müssen Sie jedes Programm ändern, das Ihr Skript aufruft. Sie haben Implementierungsdetails verloren.

Die ganze Sache mit der Dateinamenerweiterung in Mircosofts Windows ist ein Durcheinander: Zum Beispiel, was hätte sein können a.audio, b.audio, c.audio, ist a.mp3, b.wav, c.oggund d.picture, e.picture, f.pictureist d.jpeg, e.png, f.gif. Die meiste Zeit ist es uns egal, in welchem Format das Audio oder Bild vorliegt. Außerdem müssen wir neue Benutzer über einen langen Zeitraum in alle Dateierweiterungen einweisen.

— Strg-Alt-Delor
quelle

Ein weiterer Grund, warum *.shich Debian soeben nicht kennengelernt habe, ist, dass Debian run-partskeine Skripte mit Erweiterungen ausführt, wie zum Beispiel in /etc/cron.*/: archive.oreilly.com/pub/post/runparts_scripts_a_note_about.html

— Ross Patterson

3

Shell-Skript-Erweiterungen sind sehr nützlich. Zum Beispiel schreibe ich oft Skripte, die mehrere Dateien in mehreren Sprachen enthalten (z. B. bash, awk und lua), in dasselbe Verzeichnis. Wenn ich nur in den Bash-Dateien nach einer Zeichenfolge suchen muss, ist diese Erweiterung sehr praktisch, um Fehlalarme zu vermeiden. Oder wenn ich eine Zeilenzählung meines gesamten Bash-Codes für dieses Projekt durchführen möchte.

Es ist mühsam, die Erweiterung beim Ausführen des Programms eingeben zu müssen, daher erstelle ich auch einen Symlink ohne die Erweiterung zur ausführbaren Hauptdatei, um sie zu bearbeiten / auszuführen, ohne die Erweiterung jedes Mal eingeben zu müssen. Symlinks sind billig und einfach.

— Steve
quelle

Dies scheint mit unix.stackexchange.com/questions/31760/…

— Pacerier

2

Wie andere gesagt haben, kümmert sich die Shell nicht um Erweiterungen. Es ermöglicht jedoch eine schnelle Identifizierung von Dateien durch den Menschen. Ich sehe Dateien, die auf .pyoder enden, .shund weiß schnell, wie sie (zumindest) lauten sollten. Wie Steve sagt, sind die Suche nach Dateierweiterung oder die Zeilenzählung auch praktische Überlegungen.

— qwr
quelle