Lange Zeit galt in Linux-Kreisen die unausgesprochene Regel, dass PowerShell eine Windows-Sache und Bash das eigentliche Ding sei. Sogar ich vertrat zunächst diese Position, da sich die ersten Versionen von PowerShell schwerfällig anfühlten, nur für Windows gedacht waren und nicht häufig freiwillig verwendet wurden. Diese Version von PowerShell gibt es seit Jahren nicht mehr, aber die Linux-Community hat immer noch den Ruf, sie trotz ihrer Fortschritte abzulehnen.
PowerShell ist seit einem Jahrzehnt Open Source und plattformübergreifend. Es ist kein reines Windows-Verwaltungstool mehr, da es auch native Builds für Linux und macOS bietet. Früher habe ich es mir wie ein Terminal vorgestellt, das ich jedes Mal öffnen musste, wenn ein Skript für PowerShell geschrieben wurde, aber ich habe es danach ohne große Überlegung wieder geschlossen. Als ich mich mit PowerShell an ein echtes Projekt machte, wurde mir klar, dass ich es nicht länger abschreiben sollte.
Verwandte
5 PowerShell-Skripte, die jeder Windows-Benutzer kennen sollte
PowerShell kann viel
Die Objektpipeline von PowerShell ändert die Skripterstellung
Bash ist dadurch eingeschränkt, dass alles als String behandelt wird
Es hat länger gedauert, als ich zugeben möchte, herauszufinden, was PowerShell so anders als Bash macht. Es hat endlich Klick gemacht, als mir ein grundlegender Unterschied zwischen den beiden klar wurde: PowerShell leitet Objekte weiter und Bash leitet Zeichenfolgen weiter. In Bash gibt jeder Befehl Text aus, und dann finden Sie heraus, wie Sie diesen Text in etwas Nützliches umwandeln können. Dies erfordert in der Regel viele Weiterleitungen zu grep, sed und awk, um die Rohausgabe zu analysieren, selbst bei relativ einfachen Aufgaben. Diese Tools sind leistungsstark und ich verwende sie immer noch, aber ich muss zugeben, dass PowerShell viele Dinge einfacher macht.
Hier ist ein kurzes Beispiel, das meinen Standpunkt verdeutlicht. Diese PowerShell-Pipeline filtert Prozesse nach CPU-Auslastung und wählt ihren Namen aus. Alles über 10 % CPU-Auslastung wird als Ausgabe angezeigt:
Get-Process | Where-Object CPU -gt 10 | Select-Object Name
Nun, so würden Sie das Äquivalent in Bash schreiben:
ps -eo comm,pcpu | awk '$2 > 10 {print $1}'
Der Unterschied macht sich dort schon allein in der Lesbarkeit sofort bemerkbar. Aber es geht noch tiefer, denn PowerShell leitet Objekte und nicht nur Text an jeden nachfolgenden Befehl weiter. Bash verwendet awk, um die gewünschte Spalte zu isolieren und dafür zu sorgen, dass Prozesse mehr als 10 % CPU verbrauchen. Dies ist nur ein einfaches Beispiel, aber komplexere Bash-Skripte und -Pipelines verwenden awk und sed großzügig und brechen ab, wenn ihnen ein Befehl eine Ausgabe in einem Format übergibt, das überhaupt von dem abweicht, was sie erwarten.
Bei kurzen Einzeilern wie im obigen Beispiel ist der Unterschied bei alltäglichen Aufgaben nicht so wichtig. Der wahre Gewinn liegt in längeren Skripten mit echter Logik, wie bedingter Verzweigung, Fehlerbehandlung und Datentransformation. Hier zeichnet sich das Objektmodell aus. Die meisten meiner PowerShell-Skripte sind nicht nur deutlich kürzer als ihre Bash-Äquivalente, sie lassen sich auch ein paar Monate später viel einfacher erneut aufrufen. Bei Bash-Skripten, die ich eine Weile nicht berührt habe, brauche ich mindestens ein paar Minuten, um die Pipeline zu studieren und mich daran zu erinnern, wie sie die Daten manipuliert.
Bash gewinnt immer noch in Sachen Portabilität
Für meine eigenen Maschinen verschwindet dieser Vorteil
Bash ist geradezu allgegenwärtig und wird nirgendwohin führen. Sie finden es auf jedem Linux-System, zu dem Sie eine SSH-Verbindung herstellen, und jeder Docker-Container führt Sie zu der bekannten Bash-Eingabeaufforderung. Darüber hinaus können in Bash geschriebene Skripte auf fast jedes Unix-ähnliche System portiert werden und funktionieren, ohne dass Änderungen erforderlich sind. Obwohl es plattformübergreifend ist, kann PowerShell dieses Maß an Universalität nicht erreichen, sodass Sie es eigentlich nur auf Windows-Rechnern und allen anderen, die Sie steuern, erwarten können.
Anfangs war ich kein Fan der Verb-Substantiv-Namenskonvention, wie Get-ChildItem statt ls oder Set-Location statt cd. Es fühlt sich ausführlich an, aber ich habe sie durch Aliase gekürzt und seitdem die Klarheit jedes Befehls zu schätzen gelernt, da selbst Benutzer, die mit PowerShell nicht vertraut sind, die Bedeutung fast jedes Cmdlets mit einem kurzen Blick erkennen können.
Abonnieren Sie den Newsletter für Einblicke in PowerShell und Skripting
Holen Sie sich den Newsletter für eine ausführliche Berichterstattung über PowerShell, Bash und verwandte Skripttools. Die Berichterstattung umfasst Erläuterungen zur Objekt-Pipeline, plattformübergreifende Überlegungen, Befehlsvergleiche und konkrete Beispiele, die reale Kompromisse verdeutlichen.
Holen Sie sich Updates
Mit Ihrer Anmeldung stimmen Sie dem Erhalt von Newslettern und Marketing-E-Mails zu und akzeptieren unsere Nutzungsbedingungen und Datenschutzrichtlinien. Sie können sich jederzeit abmelden.
Da die meisten Skripte, die ich schreibe, ohnehin für meine eigenen Systeme bestimmt sind, spielt der Portabilitätsvorteil von Bash in meinem Heimlabor, auf virtuellen privaten Servern oder auf meiner täglichen Arbeitsstation keine große Rolle. Die plattformübergreifende Version von PowerShell verhält sich auf jedem System, auf dem ich sie ausführe, identisch. Deshalb greife ich immer dann zu ihr, wenn die Pipelines in komplexen Bash-Skripten überwältigend werden.
Was meine Windows-Systeme betrifft, bedeutet die Ausführung von WSL, dass ich ein PowerShell-Skript schreiben kann, das Windows-APIs und Linux-Dateipfade aus derselben Sitzung berührt, ohne das Tool wechseln zu müssen. Das ist etwas, was Bash einfach nicht kann. Es gibt auch keine nativen Bash-Äquivalente für Dinge wie die Fehlerbehandlung (abgesehen von Exit-Codes und Set-E, die in Pipelines bekanntermaßen unzuverlässig sind) und die Verwaltung von Anmeldeinformationen (SecureString). Diese „Nice-to-haves“ scheinen in längeren, komplexeren Skripten unverzichtbar zu sein, was für mich nur ein weiterer Grund ist, nach PowerShell zu greifen.
Es ist Zeit, den Ruf von PowerShell zu kalibrieren
Ohne Zweifel wird PowerShell Bash nicht ersetzen und muss es auch nicht. Aber es hat sich einen Platz im Toolkit von jedem verdient, der ernsthafte Skripting-Arbeiten durchführt, insbesondere in Windows- oder Hybridumgebungen. Allein die Objektpipeline ist die Lernkurve wert, und die meisten der alten Kritikpunkte sind bei nativen Builds, die auf anderen Betriebssystemen verfügbar sind, nicht mehr relevant. Die meisten Linux-Benutzer wären überrascht, was aus PowerShell geworden ist. Das heißt, falls sie sich jemals die Mühe gemacht haben, nachzuschauen.
*️⃣ Quelllink:
PowerShell ist eine Windows-Sache, das Skript wurde für PowerShell geschrieben, 5 PowerShell-Skripte, die jeder Windows-Benutzer kennen sollte , was PowerShell im Gegensatz zu Bash unterscheidet. Der wahre Vorteil liegt in längeren Skripten, , , , , Nutzungsbedingungen, Datenschutzrichtlinie Die meisten Skripte, die ich schreibe, führen WSL aus und ersetzen Bash.