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

Ich würde nur .sh etwas nennen, das soll portabel sein (und hoffentlich ist portabel).

Ansonsten denke ich, ist es einfach besser, die Sprache zu verbergen. Der aufmerksame Leser wird es tun Finden Sie es trotzdem in der Shebang-Zeile. (In der Praxis werden .bash oder .zsh usw. Suffixe selten verwendet.)

Kommentare

• Allein auf dieser Seite können wir bereits eine nicht triviale Anzahl von Personen sehen, die sie verwenden. Warum sagen Sie, dass sie selten verwendet "? Irgendwelche Zitate? Oder basiert dies nur auf Ihrer Erfahrung?
• Ich würde .bash wenn es ' zur Beschaffung bestimmt ist von einem anderen Skript und ist nur mit bash usw. kompatibel. Wenn es von einer bourne-kompatiblen Shell wie sh, dash bezogen werden kann oder bash würde ich eine .sh -Erweiterung geben. Wenn ' ausgeführt werden soll, würde ich ' keine Erweiterung einfügen.

Ich würde sagen, dass es keine „bewährten Methoden“ für Dateierweiterungen gibt, ausschließlich aus technischen Gründen: Unix / Linux / * BSD-Dateisysteme nicht Unterstützungserweiterungen an sich. Was Sie als Erweiterung bezeichnen, ist lediglich ein Suffix eines einzelnen Dateinamens. Dies unterscheidet sich von den Dateisystemen und Betriebssystemen VM / CMS, VMS, MS-DOS und Windows, bei denen ein besonderer Punkt in der Inode- Das moralische Äquivalent ist für eine Erweiterung reserviert.

Dieses kleine Geschwätz ist jetzt vorbei. Ich finde es „ein bisschen albern, ein“ .sh „- oder“ .ksh „- oder“ .bash „-Suffix auf eine Shell zu setzen Skriptdateiname. Ein Programm ist ein Programm: Es gibt keinen Vorteil bei der Unterscheidung, was ausgeführt wird. Kein Unix oder Linux oder irgendein Kernel hat beschlossen, einen Interpreter für eine Datei aufzurufen, nur weil ein Dateinamen-Suffix vorliegt #! Zeile oder eine andere „magische Zahl“ von Bytes an der Anfang der Datei. In der Tat ist die Entscheidung, was basierend auf dem Dateinamen „Erweiterung“ ausgeführt werden soll, einer der Faktoren, die Windows zu einem Malware-Magneten machen. Sehen Sie sich an, wie viele Windows-Malware-Betrügereien eine Datei mit dem Namen „Something.jpg.exe“ enthalten. Standardmäßig zeigt neueres Windows die Erweiterung „.exe“ nicht an und fordert einen Benutzer auf, einfach auf das „Bild“ zu doppelklicken Wenn eine Bildansicht ausgeführt wird, wird die Malware ausgeführt.

Was Sie möglicherweise als direkten Befehl betrachten, ist ohnehin oft ein Shell-Skript. Manchmal war cc ein sh-script, firefox ist ein sh-script, startx ist ein sh-script. Ich glaube nicht, dass es kognitiv ist oder Organisatorischer Vorteil beim Markieren eines Skripts mit dem Suffix „.sh“.

Kommentare

• Ich bin anderer Meinung! Mein Job besteht darin, eine Anwendung zu verpacken, an der Tausende von Personen beteiligt sind Dateien, die von ausführbaren Binärdateien bis zu Shell-Skripten (ksh, bash und einige ältere csh) reichen. Glauben Sie mir, es macht einen Unterschied, auf einen Blick (oder in einem regulären Ausdruck) zu wissen, was Art von Datei, die wir diskutieren und die wir suchen. Mein Punkt ist, dass es könnte b e ein Vorteil bei der Unterscheidung, was exutiert wird, und eine bewährte Methode sollten dazu ermutigen, den Dateityp explizit anzugeben.
• @rahmu: Schreiben Sie dies als Antwort auf. Geben Sie einige Details dazu an, wie durch Regex unterscheidbare Namen Ihnen helfen, diese Anwendung zu verpacken (und möglicherweise zu warten). Beachten Sie insbesondere die Wechselwirkung zwischen der Interpretation der Datei und dem Suffix ' des Dateinamens und der Unterstützung bei der Ausführung von Aufgaben. Ich ' bin an ernsthaften Argumenten gegen meinen Standpunkt interessiert und ' bin bereit, mich zu ändern, wenn ich ' Ich bin überzeugt. Ich habe Ihren Kommentar positiv bewertet, um dies zu beweisen.
• Ich würde es gerne tun, leider kann ich nur über meine aktuellen Erfahrungen in meinem aktuellen Job sprechen.Ich ' weiß nicht viel über bewährte Verfahren und Standards im Allgemeinen ; Ich denke, ich sollte etwas recherchieren, bevor ich hier eine Antwort poste. Ich ' werde mich heute Abend nach der Arbeit darum kümmern 🙂
• @rahmu Die " -Datei ist vorhanden, um den Dateityp zu bestimmen. Es ist in der Lage, Skripte zu unterscheiden, die für verschiedene Shells geschrieben wurden.
• Wenn Sie einem Shell-Skript die Erweiterung .sh geben, ' muss beim Starten das .sh als Teil des Befehlsnamens eingeben. Das ' ist der Hauptgrund, warum ich ' diese Erweiterung nicht gerne einfüge (dasselbe gilt für alles, was eine Shebang-Linie hat). Übrigens ist das Problem in Windows nicht das Präfix .exe an sich (es ist ' trivial, eine ausführbare Datei mit dem Namen schließlich unter Linux), aber die Tatsache, dass Windows diese Erweiterung normalerweise verbirgt, kombiniert mit der Tatsache, dass die zum Starten einer ausführbaren Datei und zum Öffnen eines Dokuments erforderliche Aktion genau dieselbe ist.

Als einer, der in einer Vielzahl von nix-Umgebungen gearbeitet hat, musste ich in einer Vielzahl von Umgebungen schreiben Muscheln. Ob Sie es glauben oder nicht, plattformübergreifend sind die Muscheln 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. Auf diese Weise wissen Sie, wenn Sie auf eine andere Plattform wechseln und die Shell etwas anders ist, welche Skripte für Änderungen ausgewählt werden müssen. .sh .ksh .bsh .csh …

Kommentare

• Dies scheint mit unix.stackexchange.com/questions/31760/ …
• Haben Sie keine #! zu Beginn des Skripts (z. B. #!/bin/bash)?
• Gnu / Linux, BSD und UNIX sind alle Unix. Keine Notwendigkeit für? Nix. Linux ist ein Kernel, Android verwendet Linux, aber kein Unix (es sei denn, Sie fügen zusätzliche Software hinzu. In diesem Fall haben Sie eine Unix-App).
• @ ctrl-alt-delor: " Unix " ist eine Marke . Menschen verwenden häufig "? Nix ", um das Markenproblem (und die Pedanten) zu vermeiden.
• @JS ` UNIX ' ist eine Marke von The Open Group. Unix und Unix sind nicht greens.org/about/unix.html

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.sh und schreiben dann in Python a.py neu. Jetzt müssen Sie jedes Programm ändern, das Ihr Skript aufruft , Sie haben Implementierungsdetails durchgesickert.

Die ganze Sache mit der Dateinamenerweiterung in Mircosofts Windows ist ein Chaos: Was beispielsweise a.audio, b.audio, c.audio gewesen sein könnte, ist a.mp3, b.wav, c.ogg und d.picture, e.picture, f.picture ist d.jpeg, e.png, f.gif. Meistens ist es uns egal, welches Format Das Audio oder Bild ist in. Wir müssen auch viel Zeit damit verbringen, neuen Benutzern alle Dateierweiterungen beizubringen.

Kommentare

• Ein weiterer Grund nicht *.sh zu verwenden, auf das ich gerade gestoßen bin, ist, dass Debian ' s run-parts ' Führen Sie keine Skripte mit Erweiterungen aus, z. B. in /etc/cron.*/: archive.oreilly.com/pub /post/runparts_scripts_a_note_about.html

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 .sh verwenden.

I. Verwenden Sie persönlich die folgenden Konventionen, unabhängig von der verwendeten Shell (csh, tcsh, bash, sh, …):

• keine Erweiterung für System- oder hochwertige Skripte (äußerst selten).
• die .sh für klassische Skripte, niedrig bis hochgradig.

Kommentare

• Was meinst du mit " klassischen Skripten, niedrig bis hochgradig "?
• Ich denke Damit meinte ich Abstraktion oder Organisationsebene. Das heißt, Sie ' kümmern sich nicht darum, welche Sprache / welches Skript-Tool hinter einigen Befehlen verwendet wird: ' verwenden keine Erweiterung. Für andere ist es gut zu wissen, dass es sich um eine Bash oder ein exotisches Ksh-Shell-Skript handelt (mit der richtigen Erweiterung). … aber das war vor 2 Jahren;)

Shell-Skripterweiterungen sind sehr nützlich. Zum Beispiel schreibe ich oft Skripte, die mehrere Dateien in mehreren Sprachen enthalten (z.bash, awk und lua) im selben Verzeichnis. Wenn ich nur in den Bash-Dateien nach einer Zeichenfolge suchen muss, ist die Erweiterung sehr praktisch, um Fehlalarme zu reduzieren. Oder wenn ich den gesamten Bash-Code für dieses Projekt in einer Zeilenanzahl erstellen möchte.

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

Kommentare

• Dies scheint mit unix.stackexchange übereinzustimmen. com / question / 31760 / …

Wie andere bereits gesagt haben, kümmert sich die Shell nicht um Erweiterungen. Sie ermöglicht jedoch eine schnelle Identifizierung von Dateien durch den Menschen. Ich sehe Dateien, die mit .py oder .sh und ich weiß schnell, was sie (zumindest) sein sollten. Wie Steve sagt, sind die Suche nach Dateierweiterung oder das Zählen von Zeilen ebenfalls praktische Überlegungen.