Der Vorteil von Objekten in PowerShell

Ich beschäftige mich nun schon eine ganze Weile mit PowerShell und mittlerweile habe ich das große Potential davon erkannt. Ich kann zwar noch nicht wirklich viel machen, aber die große Angst vor dem Unbekannten ist gewichen. Wer mich kennt, weiß, dass ich ursprünglich aus der Linux Welt komme. Und was macht man wenn man etwas Neues kennen lernt – man fängt das Vergleichen mit dem Bekannten an. Liegt ja auch nahe.

Nahezu alle PowerShell Einstiegs Tutorials beginnen mit der Behandlung von Prozessen. Trifft sich gut, kann man doch sehr schön Parallelen zu bekannten Linux Befehlen ziehen. Der Klassiker unter Linux ist mit Sicherheit sowas in der Art hier:

Oder, wenn man nicht so eine riesen Liste haben will, filtert man eben nach einem Prozess, hier z.B. spamd:

So wirklich aussagekräftig ist der Output an dieser Stelle noch nicht. Abgesehen von der Anzahl der Prozesse mit diesem Namen (stimmt auch nicht ganz, da natürlich mein Prozess mit der Suche aufgrund des Strings ebenfalls gefunden wird) ist die Ausgabe noch nicht sonderlich aussagekräftig. I.d.R. ist die Interessanteste Info die PID (ProcessID) in der ersten Spalte um damit dann weitere Informationen aus dem System zu erhalten.

Mit PowerShell sieht der erste Befehl, die Liste aller Prozesse, dann so aus:

In den allermeisten PowerShell Tutorials wird es dann damit weitergehen, dass der Output des Get-Process Befehls in ein weiteres CmdLet gepipet wird, in diesem Fall nach Where-Object um einen bestimmten Prozess herauszupicken:

Spätestens an dieser Stelle fängt man an zu vergleichen und denkt sich, das Konstrukt ps ax | grep ProzessName ist jetzt aber viel einfacher als get-process | where-object {$_.ProcessName -eq ‚ProzessName‘}, vor allem weil einem als Neuling das Konstrukt mit der geschweiften Klammer spanisch vorkommt. Steigt man etwas weiter in die PowerShell ein merkt man ziemlich schnell, dass das Where-Objekt Konstrukt an dieser Stelle gar nicht nötig ist, da schlicht unnötig:

Jetzt hat der Befehl doch seinen „Schrecken“ verloren, oder? 😉

Grundsätzlich hat man jetzt identische Ausgaben für einen Prozess. Wenn man sich die jeweils letzten Ausgaben, also die gefilterten Ausgaben der Prozesse, ansieht, könnte man bei der Powershell Ausgabe schon auf die Idee kommen, dass PowerShell eine ganze Reihe mehr Daten mit diesem einen Befehl liefert als der Linux ps Befehl. Und genau an dieser Stelle kommen die Objekte in PowerShell zum tragen.

Die Objekte zu den einzelnen Prozessen enthalten direkt alle (OK, fast alle, aber das sprengt jetzt den Rahmen dieses Blogposts) Informationen zu dem gewählten Prozess. Die Standardausgabe von Get-Process lässt das ja schon vermuten, sind doch Informationen zu CPU (-zeiten), Speicherverbrauch (VM), Handles, PID und dem Prozessnamen direkt sichtbar. Dies ist aber nur eine vordefinierte Auswahl, welche per Default ausgegeben werden. Will man alle Eigenschaften eines Objektes anzeigen, pipet man das Objekt an das CmdLet Format-List und sagt diesem, dass man alles sehen will:

Tatsächlich hat PowerShell mir die obige Ausgabe 4 Mal ausgegeben. Warum? Weil wir 4 Prozesse (die in diesem Fall jeweils ein eigenständiges Objekt sind!) mit dem Namen Notepad haben. Jetzt sehen wir alle Eigenschaften, die ein Objekt vom Typ Prozess (System.Diagnostics.Process) hat. Und jetzt wird es interessant. Ich muss nämlich keine zusätzlichen Befehle ausführen um z.B. aus dem Objekt eine beliebige Information zu bekommen. Über das sogenannte Powershell Parentheses, das Arbeiten mit Klammern, können wir diese Objekteigenschaften direkt aus dem Objekt ziehen:

Cool oder? Dadurch das der Befehl in Klammern gesetzt wurde, wird zunächst der Befehl ausgeführt und das Ergebnis bzw. aus dem Ergebnis wird dann die entsprechende Eigenschaft extrahiert. Letztlich funktioniert das wie in der Mathematik (5*100-10 ist was anderes als 5*(100-10)).

Und warum schreibe ich das jetzt eigentlich? Ich habe heute auf einem Windows Server das Feature „Windows Serverbackup“ installiert und ein Backup konfiguriert. Weil der Server mit einer anderen Aufgabe massiv beschäftigt war und den Servermanager nicht starten wollte (natürlich wollte er, später hatte ich dann 5 offene Servermanager :-)) habe ich die PowerShell genutzt weil ich wusste, dass Windows Serverbackup PowerShell CmdLets mitbringt. Das CmdLet Start-WBBackup erfordert die Eingabe einer Policy. Nachdem ich diese aber nicht kannte, habe ich einfach Get-WBPolicy ausprobiert, und siehe da, den Befehl gibt es. So war es einfach ohne weitere Kenntnis des Policy-Namens, das Backup zu starten. Ich habe einfach das Policy-Objekt an das CmdLet Start-WBBackup übergeben und schon lief die Sicherung:

 

Veröffentlicht in Powershell Getagged mit: ,

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*