it-swarm.com.de

Wann soll Bash und wann Perl/Python/Ruby verwendet werden?

Wir machen bisher alle unsere Skripte mit Bash, aber ich fange an, mich ein bisschen albern darüber zu fühlen. Obwohl wir mit Bash natürlich alles machen können, was wir wollen (es ist ziemlich mächtig), frage ich mich, ob wir nicht stattdessen eine richtige Skriptsprache verwenden sollten (in unserem Fall höchstwahrscheinlich Ruby).

Wie entscheiden Sie, wann Sie Perl/Python/Ruby über Bash für ein Skript verwenden? Ich denke nicht, dass ein Init-Skript mit Ruby Sinn macht, aber wie wäre es mit einem etwas längeren Skript, das E-Mail-Konten hinzufügt?

73
futlib

Angesichts eines Problems, mit dem beide umgehen können, sollten Sie das verwenden, mit dem Sie sich am wohlsten fühlen. Letztendlich gibt es viele kleine Details, und nur Erfahrung kann Sie lehren, sie zu sehen.

Bash ist eine Allzweck-Skriptsprache wie Python, Ruby und Perl, aber jede hat andere Stärken als der Rest. Perl zeichnet sich bei der Textanalyse aus, Python behauptet, das eleganteste der vielen zu sein, Bash-Skripte eignen sich hervorragend zum "Herumspielen", wenn Sie wissen, was ich meine, und Ruby ... nun, Ruby ist in vielen Dingen etwas Besonderes Von Wegen.

Die Unterschiede zwischen ihnen sind jedoch nur dann von Bedeutung, wenn Sie über ausreichend Erfahrung im Erstellen von Skripten verfügen. Ich schlage vor, dass Sie eine Sprache auswählen und sie an ihre Grenzen bringen, bevor Sie zur nächsten wechseln. In einem Shell-Skript kann man viel machen, mehr als die meisten Leute zugeben würden. Jede Sprache ist so schwer, wie Sie es wollen. Nachdem Sie ein paar Dinge geschrieben haben, ist jede Sprache für Sie "einfach".

Mit der Shell vertraut zu sein, zahlt sich schnell aus, wenn Sie unter Linux leben. Vielleicht möchten Sie damit beginnen. Wenn Sie in einem Shell-Skript eine Aufgabe finden, die Sie unmöglich oder unpraktisch lösen können, verwenden Sie etwas anderes.

Beachten Sie auch, dass das Erlernen von Shell-Skripten sehr einfach ist. Die eigentliche Stärke liegt in anderen Programmen wie awk, sed, tr, et al.

42
mkaito

TL; DR - Verwenden Sie bash only , um eine bessere Sprache zu installieren (falls diese noch nicht verfügbar ist). Andernfalls verschwenden Sie nicht behebbare, kostbare menschliche Zeit. Wenn Sie es nicht ohne Fehler von Hand auf der Kommandozeile machen können, schreiben Sie nicht mit bash/Shell.

Es ist 2015, daher würde ich Folgendes in Betracht ziehen:

  1. speicheraufwand

    • Der Speicheraufwand für die Ruby/Python-Laufzeit im Vergleich zu Bash ist gering (aufgrund der gemeinsam genutzten Bibliotheken), während ein nicht triviales Bash-Skript wahrscheinlich sowieso nicht verwaltet werden kann (d. H. Eines mit mehr als 100 Zeilen). Daher spielt die Speichernutzung keine Rolle
  2. startzeit

    • Der Start von Ruby/Python ist vielleicht ein bisschen langsamer, aber es besteht die Möglichkeit, dass Sie nicht 100 Mal pro Sekunde viele vollständige Ruby/Python-Prozesse in einer engen Schleife ausführen (wenn Sie solche Anforderungen haben, ist dies bash/Shell sowieso zu viel Aufwand und Sie müssen wahrscheinlich auf C/C++) fallen
  3. performance

    • in Ruby/Python sind fast alle typischen Datenverknüpfungen schneller - oder zumindest vergleichbar (oder Sie benötigen ohnehin C/C++/Haskel/OCaml/was auch immer).
    • die eigentliche Leistung/der Engpass bei der Ausführung (oder sogar die Produktivität) wird fast niemals "ein Mangel an bash/Shell" sein (sogar der Ubuntu-Schaltstrich beim Start zeigt, wie bash das eigentliche Problem ist - und eine Busybox ist wahrscheinlich der einzige Anwendungsfall, da es ist nichts weiter als 'bash' und 'vi' gibt, um Code zu schreiben und auszuführen, und es oft keine Möglichkeit gibt, etwas anderes hinzuzufügen/herunterzuladen oder zu speichern)
    • das Ausführen anderer Prozesse (wie sed/awk/grep) ist tatsächlich um ein Vielfaches langsamer als das Aufrufen einer Methode für ein Live-Objekt im Speicher
  4. produktivität

    • es ist zu einfach, in Bash/Shell Fehler zu machen, als "echte" Methoden, Parameter, Variablen und Ausnahmen in Ruby/Python zu verwenden
    • Agile ist Mainstream, während Bash keine Unterstützung dafür hat (fehlende Unit-Test-Funktionen, Bibliotheken, OO, Modularität, Flusen, Introspektion, Protokollierung, Metaprogrammierung; fast unmöglich zu überarbeiten, ohne etwas zu beschädigen)
    • zu viele Inkompatibilitäten mit anderen Shells führen dazu, dass kleinere Umgebungsvariablen ein Skript vollständig beschädigen (und einige wichtige Entwicklungswerkzeuge wie Puppet ignorieren Shebang-Zeilen und geben wichtige Shell-Variablen weiter oder schreiben sie neu), während Ruby/Python eine gut definierte, relativ reibungslose Migration aufweisen Pfade auch für größere Versionsänderungen
    • das Erlernen einer neuen Sprache nimmt einen Bruchteil der Zeit in Anspruch, die zum Debuggen von Shell-Skripten benötigt wird, da Shell-spezifische Probleme auftreten (insbesondere Variablennamen, keine Booleschen Werte, keine Ausnahmen usw.).
    • sogar Start-Skripte sind eine Landmine ( insbesondere , weil sie während des SystemStartvorgangs fehlschlagen können). Angesichts der jüngsten Sicherheitslücken bei bash ist es möglicherweise besser, einfaches C (mit guten Bibliotheken) zu verwenden. C muss kompiliert, konfiguriert usw. werden, aber selbst ein einfaches Shell-Skript benötigt möglicherweise ein Repository, eine Versionsverwaltung und ein Paket.
    • was auch immer mit sed/awk/grep verfügbar ist, ist wahrscheinlich bereits in Ruby/Python integriert - ohne dass es eine Abhängigkeit oder "Unterschiede" zwischen den Versionen dieser Tools auf verschiedenen Plattformen gibt (und wenn es auf Ihrem Setup funktioniert)
  5. berufssicherheit
    • was nützt es, sich einen Job zu sichern, den Sie nicht mögen? (es sei denn, Sie verbringen all diese Stunden mit schwer zu debuggenden, aber trivial zu erstellenden Shell-Skript-Fehlern)

Ich finde, es gibt keinen Grund, Bash/Shell zu verwenden, wenn Ruby/Python installiert ist.

Und wahrscheinlich wird für die Installation von Ruby/Python nicht einmal ein Bash-Skript benötigt (mit Ausnahme von busybox sind einige System-Tools ohnehin davon abhängig, dass Python/Perl vorhanden ist).

Und jedes Mal, wenn Sie ein Shell-Skript schreiben, "üben" Sie genau das - anstatt etwas Mächtigeres/Produktiveres zu lernen.

Warum benutzen die Leute heutzutage Bash? Weil es eine schreckliche Gewohnheit ist, die sich nur schwer auflösen lässt. Ein Skript ist selten nach den ersten Minuten "für immer fertig" - egal wie stark die Leute dazu neigen, so zu denken. Zusammen mit dem Irrtum "Es ist der letzte Fehler in diesem Skript".

Fazit: Benutze bash/Shell nur, wenn du absolut gezwungen bist (wie ~/.bashrc, busybox), weil es heutzutage fast nie "das richtige Werkzeug für den Job" ist.

54
Cezary Baginski

Ich benutze bash, wenn mein Hauptaugenmerk auf der Dateiverwaltung liegt. Dies kann das Verschieben, Kopieren und Umbenennen von Dateien sowie das Verwenden von Dateien als Eingabe für andere Programme oder das Speichern der Ausgabe eines anderen Programms in Dateien umfassen. Ich schreibe selten Bash-Code, der den Inhalt einer Datei untersucht oder die Ausgabe zum Schreiben in eine Datei generiert. Ich überlasse das den anderen Programmen (die ich in Perl oder Python schreiben kann), die ich über bash starte.

Ich verwende Perl und Python, wenn mein Hauptaugenmerk auf dem Lesen von Daten aus Dateien, der Verarbeitung dieser Daten und dem Schreiben von Ausgaben in Dateien liegt. Wenn ich (in Perl) den Befehl system, Back Ticks oder (in Python) das Modul subprocess zu ausführlich verwende, denke ich darüber nach, das Skript in bash zu schreiben. Andererseits fange ich manchmal an, einem Bash-Skript so viel Funktionalität hinzuzufügen, dass es irgendwann sinnvoller ist, es in Perl/Python umzuschreiben, als mich mit der (im Vergleich) eingeschränkten Unterstützung von Bash für Variablenbereiche, Funktionen, Datenstrukturen usw. Zu befassen .

28
chepner

Ich mag die Kriterien, die in diesem Blogbeitrag dargelegt werden.

  • Wenn keine Argumente übergeben werden müssen, handelt es sich wahrscheinlich um ein Shell-Skript.
  • Wenn es nicht viel für die Steuerlogik gibt (außer einer einzelnen Schleife oder if/else), ist es wahrscheinlich ein Shell-Skript.
  • Wenn die Aufgabe die Automatisierung von Befehlszeilenanweisungen ist, handelt es sich mit ziemlicher Sicherheit um ein Shell-Skript.
15
MarkTee

Ich fand diese Perl versus Bash Analyse nützlich ...

http://blogs.Perl.org/users/buddy_burden/2012/04/Perl-vs-Shell-scripts.html

Der Einfachheit halber kopiere ich eine Zusammenfassung des Autors 1) wenn Bash bessere Ergebnisse liefert und 2) wenn Perl bessere Ergebnisse liefert ...

Wenn Bash besser ist ...

  • Auftragsfehler
  • Befehle beim Beenden
  • Job-Ausgabezeilen verarbeiten
  • Hier Dokumente
  • Dateiäquivalenzen
  • Datei-Zeitstempel-Vergleiche
  • Tilde-Erweiterung

Wenn Perl besser ist ...

Perl schlägt bei den meisten Anwendungen immer noch die Nase voll. Gründe, warum ich Perl bevorzugen könnte, sind (ohne darauf beschränkt zu sein):

  • Es wird schneller. Hauptsächlich, weil ich für viele der Dinge, die ich tun möchte, keine neuen Prozesse starten muss (Basisname und Verzeichnisname sind die naheliegendsten Beispiele, aber generell können auch Ausschneiden, Grep, Sortieren und WC eliminiert werden).
  • Die Handhabung von Strings in Bash ist bestenfalls rudimentär, und die ganze $ IFS-Sache ist super-klobig.
  • Bedingungen in Shell-Skripten können fehlerhaft sein.
  • Das Zitieren in Shell-Skripten kann ein Albtraum sein.
  • die case-Anweisung von bash lässt viel zu wünschen übrig, abgesehen von einfachen Fällen (NPI).
  • Arrays in Bash saugen. Hashes in Bash (vorausgesetzt, Ihre Bash ist neu genug, um sie überhaupt zu haben) saugen noch härter.
  • Sobald die Verarbeitung von Dateien oder die Ausgabe von Befehlen über den oben aufgeführten einfachen Fall hinausgeht, beginnt Perl, heftig zu rauchen.
  • CPAN.

Es ist also nicht so, als würde Bash in naher Zukunft die Kontrolle über Perl übernehmen. Aber nach all den Jahren finde ich immer noch, dass ein einfaches Shell-Skript manchmal einfacher ist als ein einfaches Perl-Skript. Wie gesagt, ich begrüße alle Versuche, mich von etwas anderem zu überzeugen. Andererseits ist nichts falsch daran, ein paar verschiedene Werkzeuge in Ihrer Toolbox zu haben.

8
buzz3791

Nach meiner Erfahrung ist Bash versus Python ein Kompromiss zwischen Entwicklungszeit und Flexibilität. Eine rudimentäre Lösung für ein Problem kann normalerweise schneller in einem Bash-Skript erstellt werden als in einem Python-Skript.

In Python werden Sie in der Regel mehr über die Struktur Ihrer Lösung nachdenken als über das entsprechende Bash-Skript. Python ist aussagekräftiger als ein Bash-Skript und kann daher im Laufe der Zeit besser skaliert und geändert werden. Es bleibt auch im Allgemeinen besser lesbar.

Bash ist näher am Dateisystem und eignet sich hervorragend für erste Lösungsentwürfe für Probleme, die NICHT genau definiert sind. Aus diesem Grund kann ein Bash-Skript eine gute erste Wahl sein, um einen Prototyp zu erstellen, mit dem Ziel, ihn nach einem besseren Verständnis des Problems auf Python zu portieren.

5
Travis

Bash ist eine Unix-Shell, die eine Skriptsprache enthält. Es ist eher ein Befehlsprozessor. Sie steuern die Art und Weise, wie Sie Befehle ausführen, Sie führen sie tatsächlich aus.

Perl/Ruby/Python sind Allzwecksprachen.

Wenn Sie ein Shell-Skript möchten, verwenden Sie Bash

Wenn Sie eine komplexere Aufgabe haben oder nicht mit Shell in Verbindung stehen möchten. Verwenden Sie Python usw.

Ich würde diese Sprachen eigentlich nie vergleichen. Python etc. sind portabel. Sie können sie überall ausführen. Bash ist nur für Unix.

Python usw. hat Tonnen von wiederverwendbaren Bibliotheken, die Millionen von Aufgaben lösen.

Es ist fast das gleiche, wenn Sie fragen. "Wann Sie Paint und wann Photoshop verwenden sollten"

Zum Verarbeiten von E-Mails würde ich wieder Ruby verwenden, da es viele wiederverwendbare Bibliotheken gibt.

Aber der beste Weg wäre bash und Ruby zu kombinieren. Das wäre richtig. So wie Sie ein E-Mail-Verarbeitungsskript in Ruby erstellen, würden Bash-Skripte dieses Ruby-Skript aufrufen und andere Kommandos ausführen.

Wenn Sie also einen Befehlsprozessor benötigen, verwenden Sie bash. Sie führen Unix-Befehle aus und steuern sie.

UPDATE nach 7 Jahren (März 2019)

Obwohl sich der Hauptteil meiner Antwort nicht geändert hat, möchte ich darauf hinweisen.

Bash ist auch eine mächtige Skriptsprache. Für die Textverarbeitung könnte es eine absolut legitime Wahl sein.

Bitte lies die Kommentare von mkaito weiter unten. Sie sind alle völlig wahr.

4
bakytn

Shell-Skripte wie bash, ksh, zsh, sh und fish sind im Vergleich zu allgemeinen Hochsprachen wie Ruby, Python oder Perl bekanntermaßen überraschend. Während ein Shell-Skript möglicherweise als eine kürzere Datei als das entsprechende Allzweck-Skript beginnt, führen die Überraschungen zu einer Menge defensivem Umbruchcode, z. B. set -euo pipefail, um strenge Modi zu aktivieren.

Beispielsweise setzen die meisten Shell-Sprachen die Ausführung von Zeilen in einem Shell-Skript fort, selbst wenn einer der Befehle fehlschlägt. Im Gegensatz dazu versagt eine Allzwecksprache beim ersten Fehler sofort und häufig mit hoher Last, was zu einem sichereren und vorhersehbareren Verhalten in Skripten mit sogar geringer Komplexität führt.

1
mcandre

Sehr voreingenommener Artikel.

Ich finde bash nicht so schwer zu debuggen. Python ist oft viel zu starr, wohingegen man mit bash sehr kreativ sein kann. Wenn Sie ein guter Querdenker sind, werden Sie bash mögen.

Ich führe Bash-Skripte mit Millionen von DNA-Sequenzierungslesevorgängen in Tausenden von Dateien aus. Und im Gegensatz zu dem, was alle sagen, werden dieselben Versionen der Skripte in C++ nicht viel schneller ausgeführt (in wenigen Minuten werden sie voneinander getrennt).

Ich denke, dass bash wie Perl nicht besonders benutzerfreundlich und einfach zu lesen ist. Das macht den Leuten Angst, weil die meisten Leute keine großen abstrakten Denker sind. Aber hellere, kreativere Programmierer lieben es und nutzen es häufig. Wenn Sie sich selbst kennen und wissen, dass Sie ein Gehirn haben, lassen Sie sich nicht abschrecken. Wenn Sie ein Grunddenker sind, halten Sie sich vielleicht an etwas wie Python. Jedem das Seine.

1
C K

Aus dem "Lama-Buch"

  • Randal L. Schwartz, Tom Phoenix und Brian D Foy,Learning Perl(Sebastopol, CA: O’Reilly, 2011), ch. 1.2 "Wofür steht Perl?" , §§ "Warum hat Larry [der Schöpfer von Perl] nicht einfach eine andere Sprache verwendet?", S. 5:

Perl versucht, die Lücke zwischen Low-Level-Programmierung (z. B. in C oder C++ oder Assembly) und High-Level-Programmierung (z. B. "Shell" -Programmierung [z. B. bash]) zu schließen. Low-Level-Programmierung ist normalerweise schwer zu schreiben und hässlich, aber schnell und unbegrenzt; Es ist schwer, die Geschwindigkeit eines gut geschriebenen Low-Level-Programms auf einem bestimmten Computer zu übertreffen. Und es gibt nicht viel, was Sie dort nicht tun können. High-Level-Programmierung im anderen Extremfall ist in der Regel langsam, hart, hässlich und begrenzt. Es gibt viele Dinge, die Sie mit der Shell- oder Stapelprogrammierung überhaupt nicht tun können, wenn auf Ihrem System kein Befehl vorhanden ist, der die erforderliche Funktionalität bietet. Perl ist einfach, fast unbegrenzt, meist schnell und irgendwie hässlich.

0
Geremia