Profile in PowerShell: Module und Funktionen laden, Variablen setzen

    Powershell-LogoFast jeder Kommandointerpreter bietet die Möglichkeit, gleich beim Start eine vom Benutzer gewünschte Konfiguration zu laden und sich somit an individuelle Vorgaben anzupassen. Das gilt auch für die PowerShell, die gleich mehrere Profildateien ausliest, um Einstellungen für verschiedene Geltungsbereiche zu übernehmen. Zulässig ist praktisch alles, was die PowerShell ausführen kann.

    Voraussetzung dafür, dass die PowerShell beim Start eine der Profildateien lädt, ist allerdings, dass man die Ausführung von Scripts auf dem System zulässt. Dafür sind die Ausführungsrichtlinien zuständig, die per Voreinstellung auf restricted festgelegt wurden und die damit das Laden von Profilen unterbinden.

    Ausführungsrichtlinien für Scripts ändern

    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

    Die voreingestellte Ausführungsrichtlinie unterbindet das Laden von Profilen.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.

    Keine Kommentare