Was ist so toll an einer Linux Shell?
Geizhals » Forum » Linux-Support » Was ist so toll an einer Linux Shell? (33 Beiträge, 2229 Mal gelesen) Top-100 | Fresh-100
Du bist nicht angemeldet. [ Login/Registrieren ]
......
Re(6): Was ist so toll an einer Linux Shell?
16.07.2019, 01:27:07
Getestet nur unter Windows 10:


[CmdletBinding()] Param (
    [Parameter(Mandatory=$true)][ValidateSet('Off', 'On')][string]$FlightMode
)

If ((Get-Service bthserv).Status -eq 'Stopped') { Start-Service bthserv }
Add-Type -AssemblyName System.Runtime.WindowsRuntime
$asTaskGeneric = ([System.WindowsRuntimeSystemExtensions].GetMethods() | ? { $_.Name -eq 'AsTask' -and $_.GetParameters().Count -eq 1 -and $_.GetParameters()[0].ParameterType.Name -eq 'IAsyncOperation`1' })[0]
Function Await($WinRtTask, $ResultType) {
    $asTask = $asTaskGeneric.MakeGenericMethod($ResultType)
    $netTask = $asTask.Invoke($null, @($WinRtTask))
    $netTask.Wait(-1) | Out-Null
    $netTask.Result
}
[Windows.Devices.Radios.Radio,Windows.System.Devices,ContentType=WindowsRuntime] | Out-Null
[Windows.Devices.Radios.RadioAccessStatus,Windows.System.Devices,ContentType=WindowsRuntime] | Out-Null
Await ([Windows.Devices.Radios.Radio]::RequestAccessAsync()) ([Windows.Devices.Radios.RadioAccessStatus]) | Out-Null
$radios = Await ([Windows.Devices.Radios.Radio]::GetRadiosAsync()) ([System.Collections.Generic.IReadOnlyList[Windows.Devices.Radios.Radio]])
$bluetooth = $radios | ? { $_.Kind -eq 'Bluetooth' }
[Windows.Devices.Radios.RadioState,Windows.System.Devices,ContentType=WindowsRuntime] | Out-Null

switch ($FlightMode) {
       "On" {
            Get-NetAdapter | ? PhysicalMediaType -eq "Native 802.11" | Disable-NetAdapter -Confirm:$false 
            Await ($bluetooth.SetStateAsync("Off")) ([Windows.Devices.Radios.RadioAccessStatus]) | Out-Null
            }
       "Off" {
             Get-NetAdapter | ? PhysicalMediaType -eq "Native 802.11" | Enable-NetAdapter
             Await ($bluetooth.SetStateAsync("On")) ([Windows.Devices.Radios.RadioAccessStatus]) | Out-Null
       }     
}



Den BT-Teil hab ich gut aus dem Netz gestohlen (https://superuser.com/questions/1168551/turn-on-off-bluetooth-radio-adapter-from-cmd-powershell-in-windows-10 ), der WLAN-Adapter ist eh klar.

Ich hab auch leider in keinem Gerät ein WWAN-Modul, aber da könnte beim Get-NetAdapter als PhysicalMediaType "Wireless WAN" zurückkommen.
Es könnte auch sein, dass das von WinRT eh schon zurückkommt und dann so wie "Bluetooth" einfach nur zu filtern ist.

Und nein, das steuert jetzt nicht direkt die Funktion "Airplane mode", Du hast deshalb kein Flugzeug im Systray, aber der Effekt ist der Selbe.

greetz

glockman B-)

- There's no replacement for displacement. Not even Diesel. - ________________________________________________________________

Who is General Failure, and why is he reading my disk?


Diskussion beendet PM Übersicht Chronologisch Zum Vorgänger
 
Melden nicht möglich
.
Re: Was ist so toll an einer Linux Shell?
16.07.2019, 11:08:44
toll und super so eine Linux Shell doch ist.


Die Shell bietet einen textbasierten Zugang zum gesamten Betriebssystem und erlaubt somit eine textbasierte Steuerung in Ergänzung zur grafischen. Eine Shell ist also für den Profi eine sehr gute Ergänzung - vor allem wenn es um das Automatisieren von Routinetätigkeit geht. Wer also die Funktionsweise des Betriebssystems Linux verstehen will, muss sich zwangsläufig mit Shellscripts, C und er Linux-Architektur auseinandersetzen. Wer das nicht muss kann sich das auch sparen.

  super komfortabel dann die Editoren wie vi oder emacs sind, aber für längere
Scripts dann erst wieder auf Gui basierte Produkte mit Mausinput am Desktop
zurückgegriffen wird.


Ich kennen nur Vi, Vim und ich arbeite sehr gerne mit diesem Texteditor, weil er auf eigentlich jedem System verfügbar ist und das umsonst und sehr mächtig ist er auch, was das Bearbeiten von Texten betrifft. Nichtsdestotrotz arbeite ich auch gerne mit Atom oder Sublimetext - ich finde das Eine schließt das Andere nicht aus. Vor allem verwende ich gerne GUI basierte Editoren, wenn ich mit Anderen gleichzeitig über den Quellcode disktuiere und Änderungen vornehme. Am besten gefällt mir bei der Verwendung von VIM das ich direkt in der Shell bleibe und mir alle anderen Shell-Tools direkt zugänglich sind.

  ISPF Edit, gepimpt mit ein paar Editmacros, innerhalb Sekunden erledige.


Jeder sollte ruhig seinen lieblings Editor verwenden dürfen, dass kann doch den Kollegen egal sein. Man kann sowieso jede Textdatei mit jedem Editor bearbeiten. VIM bietet aber auch Makros.

  was genau ist nun so fortschrittlich an dieser Linuxshell?


Nichts es gibt sie ja auch schon ewig. Aber mit Shellprogrammierkenntnissen ist sie zur Konfiguration, Überwachung und Automatisierung von Linux-Systemen das geeignetste Mittel. Auch für das Development ist VIM in Kombination mit den Shell Kommandos, den Interpretern, Makefiles, Linkern und Compilern eine tolle Alternative zu anderen IDEs. Wenn ich mir ein neues Linux System aufsetze hole ich meine Shell-Scripts von Github, führe diese aus und mein System ist größtenteils konfiguriert.

PS:
dann vielleicht mit Pipes verketten ...


Pipes sind quasi die Superkräfte von der Shell und den Shellscripts, weil man mittels den Pipes und Redirects sehr schnell sehr komplexe und mächtige Programme erstellen kann. Indem vorgefertigte Shell-Kommandos verkettet werden und man eigene komplexere Programme aus all den verfügbaren Funktionalitäten erstellen kann, dass kompensiert auch wieder die fehlenden Objekte in gewisser weise, wie ein anderer User kritisiert hat.


16.07.2019, 12:58 Uhr - Editiert von MIMI, alte Version: hier
Diskussion beendet PM Übersicht Chronologisch Zum Vorgänger
 
Melden nicht möglich
.
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 Übersicht Chronologisch Zum Vorgänger
 
Melden nicht möglich
 

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