Profile in PowerShell: Module und Funktionen laden, Variablen setzen

Mit Hilfe des Befehls get-executionpolicy lässt sich die aktuelle Einstellung abfragen und mit

set-executionpolicy remotesigned

so ändern, dass lokale, selbst geschriebene Scripts ablaufen dürfen.

Profile abhängig von Benutzer und Host

Sind von Seiten der Rechte die Voraussetzungen geschaffen, können eine oder mehrere Profildateien angelegt werden. Unterstützt werden dabei 4 Typen mit folgenden Gültigkeitsbereichen:

• alle Benutzer, alle Shells
• alle Benutzer, aktuelle Shell
• aktueller Benutzer, alle Shells
• aktueller Benutzer, aktuelle Shell

Mit "alle Shells" sind nicht mehrere Instanzen von powershell.exe gemeint, sondern verschiedene Programme, die als Schnittstelle zur Script-Engine dienen. Die Rede ist hier auch häufig von Hosts. So lassen sich etwa verschiedene Profile für PowerShell.exe, die grafische PowerShell_ISE oder ein Produkt eines Drittanbieters definieren.

Welche Datei konkret für eine bestimmte Shell oder einen Benutzer zuständig ist, kann man den dafür vorgegebenen, selbsterklärenden Variablen entnehmen. Sie lauten:

• $Profile.AllUsersAllHosts
• $Profile.AllUsersCurrentHost
• $Profile.CurrentUserAllHosts
• $Profile.CurrentUserCurrentHost

Falls alle zulässigen Profile vorhanden sind, werden sie samt und sonders beim Start einer neuen Shell ausgeführt, und zwar in der Reihenfolge vom größten zum geringsten Gültigkeitsbereich. Die Datei für alle Benutzer und alle Shells läuft also zuerst, die für den aktuellen Benutzer und Host zuletzt. Das hat zur Folge, dass Definitionen oder Aliase in der Datei, die am genauesten auf einen Benutzer und eine Shell zugeschnitten ist, bei Namensgleichheit jene aus anderen Profilen überschreiben.

Anlegen von Profilen

PowerShell bringt standardmäßig keine Profile mit. Um festzustellen, ob eine bestimmte Profildatei existiert, empfiehlt sich die Kombination aus test-path und der Umgebungsvariable für die betreffende Datei, also beispielsweise

test-path $Profile.CurrentUserAllHosts

Ist das Ergebnis des Befehls false, dann kann man bei Bedarf eine neue Profildatei anlegen. Hilfreich ist dabei new-item, weil es zusammen mit dem Schalter -force gleich nebenbei nicht vorhandene Verzeichnisse anlegt:

new-item -path $profile -type file -force

Um die Profildatei zu editieren, kann man sie z.B. mit notepad.exe $profile öffnen.

Anwendungen für Profile

Wie sich schon aus den Namensendung .ps1 der Profildateien erkennen lässt, handelt es sich bei ihnen um normale PowerShell-Scripts, deren Besonderheit nur in ihrem Speicherort und in ihrem Namen besteht. Diese beiden Faktoren sind verantwortlich dafür, dass sie beim Start von PowerShell automatisch ausgeführt werden. Daher können sie grundsätzlich alle Möglichkeiten der PowerShell ausschöpfen.

In der Praxis wird man jedoch Profile primär dafür nutzen, um die Umgebung der Shell anzupassen, sei es, indem man Standardeinstellungen überschreibt oder Features hinzufügt.

Zur häufigsten Anwendungen der Profile zählt die Definition von Alias-Namen für Cmdlets oder von Funktionen. Erzeugt man sie nur auf der Kommandozeile, dann beschränkt sich ihre Gültigkeit auf die aktuelle Sitzung. Sollen sie permanent verfügbar sein, müssen sie in eine Profildatei aufgenommen werden. Das Gleiche gilt auch für das Laden von Modulen, das bei jedem Start einer PowerShell-Instanz wiederholt werden muss. Möchte man beispielsweise virtuelle Maschinen mit Hilfe der Management Library für Hyper-V verwalten, dann muss der Befehl

import-module Hyperv.psd1

in das Profil eingetragen werden, wenn man das Eintippen des Befehls nicht in jeder Sitzung wiederholen möchte.

Weitere Anwendungsmöglichkeiten für die Profile bestehen typischerweise darin, das Aussehen oder das Verhalten der Shell zu verändern. So könnte man etwa die Funktion prompt neu definieren, Farben von Schrift und Hintergrund verändern oder die Befehlshistorie über die Sitzung hinaus speichern.