Adventskalender 8. Dezember 2024 - PowerShell

[paedubucher]

PowerShell

Unix-Shells gibt es eine Menge, und hier im Forum dürften alle ihre wohlbegründeten Präferenzen haben. Was vielleicht weniger bekannt ist: Die PowerShell, die auf Microsofts .NET-Framework basiert, läuft auch unter Debian. Ob und inwiefern sie in dieser Umgebung eine Alternative zu den ganzen Unix-Shells darstellt, könnt ihr nun einmal selber ausprobieren.

Zum Einstieg soll man sich einiger grundlegender Unterschiede bewusst werden:

• Die PowerShell ist objektorientiert, während Unix-Shells textbasiert arbeiten.
• Die PowerShell basiert auf dem .NET-Framework, während Unix-Shells selber relativ schlanke, alleinstehende Programme sind, welche andere Programme über textuelle Schnittstellen kombinieren.
• Die PowerShell wurde auf dem Reissbrett designed, während die Unix-Shells historisch gewachsen sind.

Vor diesem Hintergrund dürften einige Unterschiede zu den Unix-Shells etwas besser nachvollziehbar sein. An vielen Stellen erkennt man aber, dass die PowerShell nützliche Features von Unix-Shells übernommen hat, wie z.B. den Pipe-Operator.

Auf das Skripting soll an dieser Stelle nicht eingegangen werden; wir begnügen uns mit Einzeilern, die aber dank Pipes doch recht nützlich werden können.

Installation

Die Ausgangslage ist eine frische Installation von Debian 12 “Bookworm” ohne GUI. Es wird ein Benutzer namens user verwendet.

Zunächst soll das .NET-Framework in der Version 8 anhand der offiziellen Anweisungen installiert werden, die ich hier abgekürzt wiedergebe.

Zunächst wird ein Paket für die Microsoft-Paketquellen installiert:

Code: Alles auswählen

$ wget https://packages.microsoft.com/config/debian/12/packages-microsoft-prod.deb -O packages-microsoft-prod.deb
$ sudo dpkg -i packages-microsoft-prod.deb
$ rm packages-microsoft-prod.deb

Anschliessend können die Paketquellen aktualisiert werden, worauf das Paket dotnet-sdk-8.0 zur Verfügung steht, das sogleich auch installiert werden soll:

Code: Alles auswählen

$ sudo apt update -y && sudo apt install -y dotnet-sdk-8.0 

Achtung: Mit der aktuellen .NET-Version 9.0 funktionierte die Installation der PowerShell nicht wie gewünscht, weswegen hier auf .NET-Version 8.0 ausgewichen worden ist!

Die Installation soll auch gleich überprüft werden:

Code: Alles auswählen

$ dotnet --version
8.0.404

Damit wäre .NET installiert. Die PowerShell kann nun als Tool von .NET installiert werden:

Code: Alles auswählen

$ dotnet tool install --global powershell

Damit die ausführbare PowerShell-Datei pwsh gefunden werden kann, soll die PATH-Variable erweitert um den Pfad der .NET-Tools ~/.dotnet/tools erweitert werden, wonach ein erneutes Einlesen von .profile (oder eine Neuanmeldung) nötig ist:

Code: Alles auswählen

echo 'export PATH="${PATH}:~/.dotnet/tools"' >> .profile
. ~/.profile

Damit ist nun die PowerShell bereit und kann mit pwsh gestartet werden:

Code: Alles auswählen

$ pwsh
PowerShell 7.4.6
PS /home/user> 

Hinweis: Auf Ausgaben wird aus Platzgründen konsequent verzichtet. Die Beispiele müssen also interaktiv durchgespielt werden, um dem Beitrag folgen zu können. (Ihr seht, ich bin nebenberuflich als Lehrer tätig.)

Hilfe und Namenskonvention

Das Hilfesystem muss zunächst aktualisiert werden, wozu eine “UICulture” angegeben werden muss, was wohl das Microsoft-Pendant zu einer Locale sein soll. Hierzu wird das Update-Help-Cmdlet (ausgesprochen: “Commandlet”) verwendet und mit dem entsprechenden Parameter aufgerufen, um das Hilfesystem in US-Englisch zu installieren.

Code: Alles auswählen

Update-Help -UICulture en-US

Damit lässt sich nun Hilfe zu einem bestimmten Thema anzeigen. Das Get-Help-Cmdlet listet eine Hilfeseite zu einem Thema ohne Paging auf, hier beispielsweise zur Registry:

Code: Alles auswählen

Get-Help Registry

Mit dem Help-Cmdlet erhält man die gleiche Ausgabe durch einen Pager dargestellt, den man mit q verlassen kann:

Code: Alles auswählen

Help Registry

Eine Liste aller Befehle erhält man mithilfe des Get-Command-Cmdlets:

Code: Alles auswählen

Get-Command

Damit sollte man gleich einen Eindruck über die Benennung von Cmdlets erhalten: Diese sind weitgehend konsequent in der Form [Verb]-[Noun] gehalten, wobei der Begriff des “Verbs” sehr weit gefasst ist. Dadurch ist es auch möglich, das Get-Command-Cmdlet nach den entsprechenden Parametern einzugrenzen:

Code: Alles auswählen

Get-Command -Verb Remove
Get-Command -Noun Process

Einige Befehle wie z.B. echo entziehen sich dieser Konvention. Dies liegt daran dass es sich hierbei um ein Alias handelt:

Code: Alles auswählen

Get-Alias -Name echo

Betrachtet man die Ausgabe des Befehls, erkennt man, dass echo bloss ein Alias für Write-Output ist. Wer herausfinden will, wie man mit Aliasen umgeht und eigene definiert, dürfte sich folgendermassen darüber schlau machen können:

Code: Alles auswählen

Get-Command -Noun Alias

Einige Aliase (bzw. deren Anwendungen), die Unix-Benutzern bekannt vorkommen sollten, werden hier wiedergegeben:

• cd PATH -> Set-Location -Path PATH
• mkdir FOLDER -> New-Item FOLDER -ItemType Directory
• dir -> Get-ChildItem
• ls /etc | head -25 -> Get-ChildItem -Path /etc | Select-Object -First 25

Providers

Ein weiteres grundlegendes Konzept der PowerShell sind die sogenannten Provider, wodurch verschiedene Datenquellen wie das Dateisystem, Umgebungsvariablen, die Registry usw. mit einer möglichst einheitlichen Schnittstelle zugreifbar gemacht werden sollen.

Diese Datenquellen werden durch die Angabe von einem Drive-Präfix voneinander unterschieden:

• Registry: HKLM für HKEY_LOCAL_MACHINE und HKCU für HKEY_CURRENT_USER
• FileSystem: C für das Laufwerk C:\ und Temp für temporäre Daten
• Environment: Env für Umgebungsvariablen

Jeder Provider hat seine eigenen Items. Was man mit einem solchen Item machen kann, lässt sich am besten über eine Befehlsauflistung dazu herausfinden:

Code: Alles auswählen

Get-Command -Noun *Item*

Dank der Wildcards werden auch Nouns wie ItemProperty und ChildItem berücksichtigt.

Einige Anwendungsbeispiele hierzu:

• Erstellen einer neuen Umgebungsvariablen FOO=123 und anschliessendes Auslesen des Wertes:
  • Set-Item -Path Env:/FOO -Value 123
  • Get-Item -Path Env:/FOO
• Erstellen eines Verzeichnisses foo im Dateisystem:
  • New-Item foo -ItemType Directory
• Setzen der Registry-Einstellung EnableAeroPeek auf den Wert 0 (nur unter Windows):
  • Set-ItemProperty -Path dwm -PSProperty EnableAeroPeek -Value 0

Weitere Provider wie ein ActiveDirectory oder Azure können über Module nachgerüstet werden, worauf hier nicht eingegangen werden soll.

Objekte

Die PowerShell arbeitet nicht textbasiert sondern objektorientiert. Werden Ergebnisse von Befehlen per Pipe an den nächsten Befehl weitergeleitet, betrifft dies nicht die textuelle Repräsentation des Objekts, sondern das Objekt als Ganzes. Die Ausgabe unterscheidet sich dadurch vom übergebenen Wert.

Objekte werden standardmässig tabellarisch dargestellt, wobei nur eine Untermenge ihrer Properties tabellarisch dargestellt wird:

Code: Alles auswählen

Get-ChildItem -Path /etc

Möchte man herausfinden, welche Properties zur Verfügung stehen, ist das Get-Member-Cmdlet hilfreich:

Code: Alles auswählen

Get-ChildItem -Path /etc | Get-Member -MemberType Property

Neben Properties gibt es auch Methoden, die auf einem Objekt aufgerufen werden können:

Code: Alles auswählen

Get-ChildItem -Path /etc | Get-Member -MemberType Method

Mit dem Select-Object-Cmdlet lassen sich nun die gewünschten Properties anzeigen:

Code: Alles auswählen

Get-ChildItem -Path /etc | Select-Object -Property FullName,CreationTime

Eine Sortierung kann mit dem Sort-Object-Cmdlet erreicht werden:

Code: Alles auswählen

Get-ChildItem -Path /etc | Select-Object -Property FullName,CreationTime | Sort-Object -Property CreationTime

Eine Filterung erreicht man über das Where-Object-Cmdlet:

Code: Alles auswählen

Get-ChildItem -Path /etc | Where-Object -Property Name -Like *net*

Ausblick

Dies soll nur eine kurze Einführung in die PowerShell sein. Freundet man sich erst einmal mit den Konzepten an, kann man auch unter Windows recht produktiv arbeiten. (Die hier verwendete Syntax ist aus didaktischen Gründen überaus umständlich gewählt. In der Praxis muss man dank verschiedener Abkürzungsmöglichkeiten wesentlich weniger Tipparbeit leisten.) Wichtig ist, dass Microsoft mittlerweile konsequent darauf achtet, dass sich alle Administrationsaufgaben über entsprechende Cmdlets vornehmen und sich dadurch automatisieren lassen. Das ist ein grosser Fortschritt gegenüber der “Click-Ops”-Welt, mit der man Windows-Systemadministratoren lange Zeit verbunden hat.

Wer mehr über die PowerShell erfahren will, dem empfehle ich das Buch Learn PowerShell in a Month of Lunches (4. Ausgabe) von Manning. Eine pragmatische Zusammenfassung davon findet sich in meinem GitHub-Repository learning-powershell.

Unter Debian werde ich für den Alltag sicher bei der Bash bleiben; einfach, weil diese überall anzutreffen ist. Unter Windows sehe ich die PowerShell aber als eine Chance vom hektischen Klicken zum Automatisieren zu kommen.

Was hält ihr von der PowerShell?

[inne]

Guten Morgen!

Auf dieses Türchen war ich sehr gespannt. Es ist Dir gut gelungen.
Ich kenne die PowerShell nur von Windows. Werde die nun aber in einer VM auch mal unter Debian installieren und testen.
Anbei möchte ich noch folgendes erwähnen: Einige schöne Beispiele findet man auch hier: https://github.com/fleschutz/PowerShell

[paedubucher]

Guten Morgen!

Auf dieses Türchen war ich sehr gespannt. Es ist Dir gut gelungen.
Ich kenne die PowerShell nur von Windows. Werde die nun aber in einer VM auch mal unter Debian installieren und testen.
Anbei möchte ich noch folgendes erwähnen: Einige schöne Beispiele findet man auch hier: https://github.com/fleschutz/PowerShell

Vielen Dank! Das ist ja eine schöne Sammlung

Leider bin ich nach dem Durcharbeiten des verlinkten Buches nicht mehr dazu gekommen, mich mit der PowerShell zu beschäftigen. Von daher fehlt mir schon etwas der Praxisbezug. Müsste ich mich mit Azure befassen, würde ich das aber garantiert mit dem entsprechenden PowerShell-Modul machen.

[mn77de]

Einen wunderschönen guten Morgen und vielen Dank für dieses interessante Türchen!

Ich persönlich halte ja nicht viel von Microsoft, weshalb ich ja auch "Debian GNU/Linux" verwende
Aber es ist trotzdem immer interessant, mit offenen Augen durch die Welt zu gehen. Alle existierenden und etablierten Software-Produkte haben ja irgendwo ihre Berechtigung, ansonsten wären sie eben gar nicht da.

Die Powershell hab ich nach der Anleitung gleich mal als Root installiert, was Unsinn ist ... dies sollte man als normaler user machen.

Was mir gleich auffällt:

Code: Alles auswählen

Sie können das Erfassen von Telemetriedaten deaktivieren, indem Sie die Umgebungsvariable DOTNET_CLI_TELEMETRY_OPTOUT in Ihrer bevorzugten Shell auf "1" oder TRUE festlegen.

Wo kann man das einstellen?

Den Pfad für die Installation der Powershell finde ich etwas abenteuerlich gewählt:

Code: Alles auswählen

~/.dotnet/tools/.store/powershell/7.4.6/powershell/7.4.6/tools/net8.0/any

Für meinen Geschmack ist die Powershell etwas zuuuu "konstruiert". Aber sie passt perfekt ins Windows-Ökosystem und ist dort sicherlich ein guter und wichtiger Schritt vorwärts.

In der Linux-Welt wird die Powershell wohl nicht mit ZSH oder Fish konkurrieren können.

An der Stelle möchte ich, einfach als Kontrast zur Powershell, auf eine sehr interessante Shell hinweisen: Die Nushell
https://www.nushell.sh/book/quick_tour.html

So etwas ist damit möglich und schon irgendwie fein:

Code: Alles auswählen

ls | where size > 1mb | sort-by size | reverse

[paedubucher]

Einen wunderschönen guten Morgen und vielen Dank für dieses interessante Türchen!

[...]

An der Stelle möchte ich, einfach als Kontrast zur Powershell, auf eine sehr interessante Shell hinweisen: Die Nushell
https://www.nushell.sh/book/quick_tour.html

So etwas ist damit möglich und schon irgendwie fein:

Code: Alles auswählen

ls | where size > 1mb | sort-by size | reverse

Vielen Dank für die positive Rückmeldung! Die Nushell sieht syntaktisch doch recht interessant aus. Was aber für mich immer eine höhere Priorität hat: Ist es überall verfügbar bzw. sogar vorinstalliert? Von daher versuche ich lieber mit den verfügbaren Werkzeugen so gut wie möglich leben zu können, als mir neue zu Suchen, die dann kaum adaptiert werden. Ich bin ein "late adopter", aber schaue gerne mal über den Tellerrand, wenn sich etwas zu etablieren abzeichnet.

[Liffi]

Witzig, hatte auch überlegt, die nushell anzuführen, insbesondere weil sie wohl schneller starten soll als die PowerShell.
Dennoch denke ich, dass beide sehr spannende Konzepte mitbringen. Ich liebe grundsätzlich shells und die Fähigkeiten, die sie mitbringen, inbesondere das Pipen von Daten von einem zu einem anderen Programm. Leider ist es bei komplexeren Daten manchmal ein bisschen hakelig und hier sind natürlich sowohl PowerShell als auch nushell vorne dabei beim Übergeben komplexer Objekte.
Im Moment zöger ich noch mit einem Wechsel, weil ich die POSIX-Kompatibiltät vielleicht vermissen würde, aber ich schiele schon immer wieder mal rüber .

[mn77de]

Ich bin ein "late adopter", aber schaue gerne mal über den Tellerrand, wenn sich etwas zu etablieren abzeichnet.

Das finde ich eine gute und vernünftige Einstellung. Mir ist ein absolut solides und stabiles System wichtig, auf das ich mich verlassen kann. Das Handwerkszeug muss funktionieren, einsatzbereit sein, und natürlich muss man auch damit umgehen können. Mit ein Grund, warum ich langfristig schon auf Debian Stable setze.

Über den Tellerrand schauen ist aber auch definitiv wichtig. Jeder ist ja doch irgendwie in seiner eigenen Blase unterwegs.

[whisper]

Powershell for Linux.
Brauchte ich mal vor etlichen Jahren, weil eine LDAP Abfrage (genauer Active Directory) mit awk und Konsorten nicht wasserdicht zu bekommen war.
Mit dem Powershell Oblekt Ansatz war es dann kein Problem, fast schon Baby leicht.
Man gut, dass das vorbei ist ...

[paedubucher]

Powershell for Linux.
Brauchte ich mal vor etlichen Jahren, weil eine LDAP Abfrage (genauer Active Directory) mit awk und Konsorten nicht wasserdicht zu bekommen war.
Mit dem Powershell Oblekt Ansatz war es dann kein Problem, fast schon Baby leicht.
Man gut, dass das vorbei ist ...

Man muss es so sehen: Wenn ich vor 20 Jahren eine Aufgabe bekommen hätte, welche komplizierte Operationen in einem Active Directory beinhaltete, hätte ich in die zuerst Tischkante gebissen und wäre dann einige Tage passiv-aggressiv unterwegs gewesen, bis ich mir die passende Klick-Sequenz angeeignet hätte. Mittlerweile kann man das auf der PowerShell recht nachvollziehbar automatisieren, und dazu kann man sogar noch auf Linux bleiben, wenn einem das wichtig ist. Man kann sich aufs Problemlösen konzentrieren und lernt dabei noch ein Werkzeug kennen, worüber man sich dabei eine qualifizierte Meinung bilden kann. Das heisst nicht, dass man deswegen Microsoft nun zu "den Guten" zählen sollte, oder seine bevorzugte Unix-Shell durch die PowerShell ersetzen muss. Es heisst einfach, dass das Leben etwas erträglicher geworden ist.

[whisper]

Der Server, auf dem ich das benutze, war ein Linux RedHat glaube ich und das Active Directrory irgend ein Windows Server.
Mein Job war eine Konvertierung von einigen User Feldern in eine andere DB, die wiederrum zu einer anderen Abteilung gehörte.

Schräge Anforderungen, die dann auch noch dauernd geändert wurde. Der tägliche Wahnsinn eben.