Re: Was ist so toll an einer Linux Shell?
Geizhals » Forum » Linux-Support » Was ist so toll an einer Linux Shell? (33 Beiträge, 2176 Mal gelesen) Top-100 | Fresh-100
Du bist nicht angemeldet. [ Login/Registrieren ]
.  Re: Was ist so toll an einer Linux Shell?
 (colo am 16.07.2019, 10:16:40)
.  Re: Was ist so toll an einer Linux Shell?
 (MIMI am 16.07.2019, 11:08:44)
..  Re(2): Was ist so toll an einer Linux Shell?  (MIMI am 16.07.2019, 12:29:42)
..  Re(2): Was ist so toll an einer Linux Shell?  (MIMI am 16.07.2019, 12:32:24)
.  Re: Was ist so toll an einer Linux Shell?
 (Bucho am 19.07.2019, 23:02:51)
.
Re: Was ist so toll an einer Linux Shell?
22.07.2019, 15:55:33
1. Reproduzierbarkeit

Es fängt bei alltäglicher Doku an. GUIs zu dokumentieren ist schwierig. Textbeschreibungen haben viele Fallstricke, Screenshots ebenso. Letztere brauchen vielleicht rote Kreise, um auf die wichtigen Punkte hinzuweisen. Videos wiederum taugen nicht, um sie zu überfliegen. Und alle haben das Problem, dass sich GUIs gerne ändern, sowohl im Stil als auch in der Anordnung. Wenn man also GUI-Automatisierungstools, die es ja gibt, einsetzt, muss man höllisch aufpassen, dass die Makros zur Version der Anwendung und/oder des Betriebssystems passen.

CLIs sind normalerweise stabil. Deshalb ist auch die Syntax mancher besonders alter Programme anders, z.B. von dd, welches anno 1974 (!!) entwickelt wurde. Damit werden Dokus zum Kinderspiel; tatsächlich muss man oft wenig selbst machen außer Kopieren & Einfügen in der Shell. Zusätzlich ist gerade im *nix-Umfeld viel (aber leider nicht mehr alles :-( ) in man-Pages dokumentiert, d.h. man kann sich oft sehr einfach aus einer vermeintlich kryptischen Befehlskette ableiten, was da passiert. Screenshots mögen oberflächlich oft leichter verständlich sein, aber finde einmal die Dokumentation, was eine bestimmte Funktion jetzt eigentlich im Detail tut … Shell-Kommandos sind also prinzipiell selbst-dokumentierend. Deswegen reicht als erste Iteration einer Dokumentation schlicht das verwendete Kommando.

Die logische Weiterentwicklung davon sind Configuration Management, Infrastructure as Code und Versionierung, wobei man dabei normalerweise weit über klassisches Shell-Scripting hinausgeht - aber es ist ein Eckstein, genau wie die Philosophie „everything is a file“. Letzteres ist übrigens mit ein Grund, warum die Shell „funktioniert“ — vieles ist Datei-Manipulation mit Standardwerkzeugen, die wie Lego-Bausteine zusammengesetzt werden können.

2. Anpassungsfähigkeit und Reduktion auf das Wesentliche

Ein Kernaspekt ist meines Erachtens, dass gute Werkzeuge einem nur exakt die Informationen geben, die man möchte, in der Form, die man abfragen möchte. Es ist toll, dass seit einiger Zeit immer wieder altehrwürdige Kommandos mit z.B. JSON-Output-Optionen aufgerüstet werden. Aber schon davor war es gang und gäbe, verschiedene Ausgabeformate, -ordnungen und -mengen zu definieren. Z.B. bei ls. Klar kann man auch den Windows Explorer umkonfigurieren, aber die Mausklicks dauern ein bisserl länger als ein paar Parameter zu tippen - vorausgesetzt, man kennt sie auswendig. Das tut man oft nicht, aber dafür gibt es auch so etwas, das sich Shell Autocompletion nennt. Tab, Tab, Tab!

Gerade auch die Arbeit mit entfernten Rechnern ist dadurch extrem viel effizienter. Man mag ein GbE-Netz haben, aber RDP und VNC werden *immer* langsamer sein als ssh. Das Tastaturkürzel dann unabsichtlich lokal statt remote eine Aktion auslösen oder einfach nicht funktionieren, davon reden wir erst gar nicht. Und auch was Skripting angeht, ist Text hier deutlich im Vorteil. Typische KVM-Java-Applets sind praktisch unmöglich zu automatisieren und die Hölle, vor allem mit veraltetem Java und ungültigen Zertifikaten. HTML5 hat’s ein bisschen besser gemacht, aber ist wenn auch noch am ehesten über JavaScript automatisierbar. Serielle Konsolen lassen gegenüber SSH zwar zu wünschen übrig, lassen sich aber simpel z.B. über Python skripten. Vor allem, weil die Ausgabe Text ist (außer, man hat Pech und es rutscht Binärzeug rein), den man im Gegensatz zu Bildern sehr leicht verarbeiten kann.

3. Unabhängigkeit von den Fähigkeiten eines einzelnen Werkzeugs

Logik, Verkettung von Kommandos durch die Nutzung von Pipes, etc. lassen es zu, Funktionsbeschränkungen von Programmen zu umschiffen. Z.B. möchte ich gerne die SMART-Testergebnisse all meiner Festplatten bekommen, aber `smartctl` erlaubt nur je eine Platte je Ausführung. Außerdem kotzt es jedesmal einen Header raus, aber nennt nicht die Festplatte (lässt sich vielleicht konfigurieren …). Das lässt sich extrem schnell und einfach abfackeln:

  for disk in /dev/sd?; do echo -n "${disk}: "; smartctl -H "${disk}" | grep health; done

Mit ein bisschen Übung in Shell-Scripting denkt man über so etwas nicht lange nach sondern tippt es einfach so runter. Wenn man einen Fehler macht, ist er meistens schnell entdeckt und sehr leicht zu korrigieren. Und durch die Shell History sieht man auch, was die Kollegen so gemacht haben.

Um auf die genannten Logfiles zu sprechen zu kommen: Das hängt wohl auch davon ab, über welche man genau spricht. Obwohl ich z.B. journald wegen des binären Speicherformats verhalten gegenüberstehe, schätze ich journalctl, weil es mir sehr mächtige Funktionen zur Filterung, Sortierung und Ausgabe an die Hand gibt. Und wenn es etwas nicht kann, kommt eben wieder Piping ins Spiel. Da es auch JSON beherrscht, ist es trivial beliebige Analysewerkzeuge darauf anzusetzen, z.B. aus der Python-Welt. Oder man nutzt gleich Graylog, ElasticSearch, etc. für zentralisiertes Logging. Da bekommst du dann auch wieder dein GUI in Form von z.B. Kibana oder Grafana. Ich wage zu behaupten, dass diese (FLOSS!) Werkzeuge unter anderem deshalb entstanden sind, weil es so leicht war, an die Daten zu kommen und sie weiter zu verarbeiten. Es ist verdammt leicht, ein erstes Skript mit Standardwerkzeugen zu schreiben, dass Daten aus /var/log ausliest und sie zu verarbeiten. Dann baut man die Fähigkeiten immer weiter aus.

4. Tastatur-zentrisch

Eine Geschmacksfrage, aber die Hand von der Tastatur zu nehmen würde mich in vielen Fällen ausbremsen. Zwar bin ich nicht so extrem, dass ich ganz auf eine Maus verzichten würde, aber als ich letztens im NextCloud-WebUI ca. hundertfünfzig mal (nicht übertrieben!) bei den App-Tokens auf „Löschen“ und den versetzten „Ja wirklich“-Knopf klicken habe müssen, hab’ ich schon sehr geflucht. Ein CLI-Tools, in dem man sich die App-Tokens auflisten lassen und löschen kann, hätte mir das Leben extrem erleichtert, selbst eine Sicherheitsabfrage hätte ich mit `yes` (`man yes`) quasi umgehen können …



Der Nachteil der Shell unter Linux und *nix generell ist, dass die Programme untereinander nicht konsistent sind. Das könnte ein Vorteil der Powershell sein, die ja objektorientiert arbeitet. Selbst arbeite ich nicht mit Microsoft-Produkten, deshalb kann ich dazu keine weitergehende Einschätzung treffen. Aber die Zukunft der *nix-Infrastruktur geht sowieso in Richtung JSON, YAML und REST-APIs, z.B. in Form von Kubernetes.


PS: Dadurch, *wie* die Shell funktioniert, kann man sie auch leicht manipulieren. Wenn ein bestimmtes Kommando z.B. für normale Benutzer nicht ausführbar ist, aber in einem anderen Programm ausgeführt wird, kann man ein Dummy-Programm in Form eines Skriptes verfügbar machen, dass im Such-Pfad (Umgebungsvariable PATH) früher kommt und z.B. eine Standardantwort liefert. Oder man schreibt einen Wrapper, der z.B. ein Programm immer mit bestimmten Parametern und Umgebungsvariablen startet (jaja, ich weiß, könnte man auch über ein Alias lösen).

Diskussion beendet PM Alle Chronologisch Zum Vorgänger
 
Melden nicht möglich
. PLONKED von Erinaceidae: Spam   (Aiden001 am 09.09.2019, 13:04:54)
. PLONKED von Erinaceidae: spam   (attentool am 09.12.2019, 07:41:59)
 

Dieses Forum ist eine frei zugängliche Diskussionsplattform.
Der Betreiber übernimmt keine Verantwortung für den Inhalt der Beiträge und behält sich das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
Datenschutzerklärung