Verwenden experimenteller Features in PowerShell

Die Unterstützung experimenteller Features in PowerShell stellt einen Mechanismus bereit, über den experimentelle Features und vorhandene stabile Features in PowerShell oder PowerShell-Modulen parallel genutzt werden können.

Ein experimentelles Feature ist ein Feature, dessen Entwurf noch nicht finalisiert ist. Das Feature wird bereitgestellt, damit die Benutzer es testen und Feedback dazu senden können. Sobald ein experimentelles Feature finalisiert wurde, werden die Designänderungen zu Breaking Changes.

Weitere Informationen zum Aktivieren oder Deaktivieren dieser Features finden Sie unter Grundlegendes zu experimentellen Features.

Lebenszyklus experimenteller Funktionen

Das Cmdlet Get-ExperimentalFeature gibt alle experimentellen Funktionen zurück, die PowerShell zur Verfügung stehen. Experimentelle Funktionen können aus Modulen oder dem PowerShell-Modul stammen. Modulbasierte experimentelle Funktionen sind erst verfügbar, nachdem Sie das Modul importiert haben. Im folgenden Beispiel wird die PSDesiredStateConfiguration nicht geladen, sodass die PSDesiredStateConfiguration.InvokeDscResource-Funktion nicht verfügbar ist.

Get-ExperimentalFeature

Name                             Enabled Source   Description
----                             ------- ------   -----------
PSCommandNotFoundSuggestion        False PSEngine Recommend potential commands based on fuzzy searc…
PSCommandWithArgs                  False PSEngine Enable `-CommandWithArgs` parameter for pwsh
PSFeedbackProvider                  True PSEngine Replace the hard-coded suggestion framework with …
PSLoadAssemblyFromNativeCode       False PSEngine Expose an API to allow assembly loading from nati…
PSModuleAutoLoadSkipOfflineFiles    True PSEngine Module discovery will skip over files that are ma…
PSSerializeJSONLongEnumAsNumber     True PSEngine Serialize enums based on long or ulong as an nume…
PSSubsystemPluginModel              True PSEngine A plugin model for registering and un-registering…

Verwenden Sie die Cmdlets Enable-ExperimentalFeature und Disable-ExperimentalFeature, um eine Funktion zu aktivieren oder zu deaktivieren. Sie müssen eine neue PowerShell-Sitzung beginnen, damit diese Änderung aktiviert wird. Führen Sie den folgenden Befehl aus, um die PSCommandNotFoundSuggestion-Funktion zu aktivieren:

Enable-ExperimentalFeature PSCommandNotFoundSuggestion

WARNING: Enabling and disabling experimental features do not take effect until next start
of PowerShell.

Wenn eine experimentelle Funktion zur Mainstream-Funktion wird, ist sie nicht mehr als experimentelle Funktion verfügbar, da die Funktionalität jetzt Teil der PowerShell-Engine oder des Moduls ist. Beispielsweise wurde die PSAnsiRenderingFileInfo-Funktion in PowerShell 7.3 eine Mainstream-Funktion. Sie erhalten diese Funktion automatisch.

Wenn eine experimentelle Funktion eingestellt wurde, ist diese Funktion in PowerShell nicht mehr verfügbar. Beispielsweise wird die PSNativePSPathResolution-Funktion in PowerShell 7.3 nicht mehr unterstützt.

Verfügbare Features

Dieser Artikel beschreibt, welche experimentellen Features verfügbar sind und wie sie verwendet werden.

Legende

• Das Symbol zeigt an, dass das experimentelle Feature in dieser Version von PowerShell verfügbar ist.
• Das Symbol zeigt die Version von PowerShell an, in der das experimentelle Feature zur Standardversion hinzugefügt wurde.
• Das Symbol zeigt die Version von PowerShell an, in der das experimentelle Feature entfernt wurde.

Name	7.2	7.4	7.5 (Preview)
PSCommandNotFoundSuggestion
PSDesiredStateConfiguration.InvokeDscResource
PSNativePSPathResolution
PSSubsystemPluginModel
PSNativeCommandArgumentPassing
PSAnsiRenderingFileInfo
PSLoadAssemblyFromNativeCode
PSNativeCommandErrorActionPreference
PSFeedbackProvider
PSModuleAutoLoadSkipOfflineFiles
PSCommandWithArgs
PSNativeWindowsTildeExpansion
PSRedirectToVariable
PSSerializeJSONLongEnumAsNumber

PSAnsiRenderingFileInfo

Die ANSI-Formatierungsfunktionen wurden in PowerShell 7.2 hinzugefügt. Dieses Feature fügt das $PSStyle.FileInfo-Member hinzu und ermöglicht die Färbung bestimmter Dateitypen.

• $PSStyle.FileInfo.Directory – Integriertes Member zum Angeben der Farbe für Verzeichnisse
• $PSStyle.FileInfo.SymbolicLink – Integriertes Member zum Angeben der Farbe für symbolische Verknüpfungen
• $PSStyle.FileInfo.Executable – Integriertes Member zum Angeben der Farbe für ausführbare Dateien
• $PSStyle.FileInfo.Extension – Verwenden Sie dieses Member, um Farben für verschiedene Dateierweiterungen zu definieren. Das Extension-Member enthält bereits Erweiterungen für Archiv- und PowerShell-Dateien.

Weitere Informationen finden Sie unter about_Automatic_Variables.

PSCommandNotFoundSuggestion

Empfiehlt potenzielle Befehle basierend auf einer Fuzzysuche nach einer CommandNotFoundException.

PS> get

get: The term 'get' isn't recognized as the name of a cmdlet, function, script file,
or operable program. Check the spelling of the name, or if a path was included, verify
that the path is correct and try again.

Suggestion [4,General]: The most similar commands are: set, del, ft, gal, gbp, gc, gci,
gcm, gdr, gcs.

PSCommandWithArgs

Dieses Feature aktiviert den Parameter -CommandWithArgs für pwsh. Mit diesem Parameter können Sie einen PowerShell-Befehl mit Argumenten ausführen. Im Gegensatz zu -Command füllt dieser Parameter die integrierte $args-Variable auf, die vom Befehl verwendet werden kann.

Die erste Zeichenfolge ist der Befehl, und nachfolgende Zeichenfolgen, die durch Leerzeichen getrennt sind, sind die Argumente.

Beispiel:

pwsh -CommandWithArgs '$args | % { "arg: $_" }' arg1 arg2

Dieses Beispiel erzeugt die folgende Ausgabe:

arg: arg1
arg: arg2

Dieses Feature wurde in PowerShell 7.4-preview.2 hinzugefügt.

PSDesiredStateConfiguration.InvokeDscResource

Aktiviert die Kompilierung in MOF auf Nicht-Windows-Systemen sowie die Verwendung von Invoke-DSCResource ohne LCM.

Ab PowerShell 7.2 wurde das PSDesiredStateConfiguration-Modul entfernt, und dieses Feature ist standardmäßig deaktiviert. Um diese Funktion zu aktivieren, müssen Sie das Modul PSDesiredStateConfiguration, v2.0.5 aus dem PowerShell-Katalog installieren und die Funktion aktivieren.

DSC v3 verfügt nicht über dieses experimentelle Feature. DSC v3 unterstützt nur Invoke-DSCResource; die MOF-Kompilierung wird weder verwendet noch unterstützt. Weitere Informationen finden Sie unter PowerShell Desired State Configuration v3.

PSFeedbackProvider

Wenn Sie dieses Feature aktivieren, verwendet PowerShell einen neuen Feedbackanbieter, um Ihnen Feedback anzuzeigen, wenn ein Befehl nicht gefunden werden kann. Der Feedbackanbieter ist erweiterbar und kann von Drittanbietermodulen implementiert werden. Der Feedbackanbieter kann von anderen Subsystemen wie dem Vorhersagesubsystem verwendet werden, um vorhersagbare IntelliSense-Ergebnisse bereitzustellen.

Dieses Feature umfasst zwei integrierte Feedbackanbieter:

• GeneralCommandErrorFeedback erfüllt die gleiche Vorschlagsfunktionalität wie heute.

• UnixCommandNotFound ist unter Linux verfügbar und bietet Feedback ähnlich wie Bash.

  UnixCommandNotFound dient sowohl als Feedbackanbieter als auch als Prädiktor. Der Vorschlag aus dem Befehl „Command-not-found“ wird sowohl für die Bereitstellung des Feedbacks verwendet, wenn der Befehl in einer interaktiven Ausführung nicht gefunden werden kann, als auch für die Bereitstellung von vorhersagbaren IntelliSense-Ergebnissen für die nächste Befehlszeile.

Diese Funktion wurde in PowerShell 7.4-preview.3 hinzugefügt.

PSLoadAssemblyFromNativeCode

Macht eine API verfügbar, um das Laden von Assemblys aus nativem Code zuzulassen.

PSModuleAutoLoadSkipOfflineFiles

Wenn dieses Feature aktiviert ist, löst PowerShell nicht mehr den Download aller in diesem Ordner enthaltenen Dateien aus, wenn der PSModulePath von Benutzer*innen einen Ordner eines Cloudanbieters wie OneDrive enthält. Alle als nicht heruntergeladen gekennzeichneten Dateien werden übersprungen. Benutzer*innen, die Cloudanbieter nutzen, um ihre Module zwischen Computern zu synchronisieren, sollten den Modulordner als angeheftet oder mit einem entsprechenden Status bei anderen Anbieter als OneDrive kennzeichnen. Wenn Sie den Modulordner als angeheftet kennzeichnen, stellen Sie sicher, dass die Dateien immer auf dem Datenträger gespeichert werden.

Diese Funktion wurde in PowerShell 7.4-preview.1 hinzugefügt.

PSNativeCommandArgumentPassing

Wenn dieses experimentelle Feature aktiviert ist, verwendet PowerShell die ArgumentList-Eigenschaft des StartProcessInfo-Objekts anstelle unseres aktuellen Mechanismus zum Rekonstruieren einer Zeichenfolge beim Aufrufen einer nativen ausführbaren Datei.

Dieses Feature fügt eine neue $PSNativeCommandArgumentPassing-Einstellungsvariable hinzu, die dieses Verhalten steuert. Mit dieser Variable können Sie das Verhalten zur Laufzeit auswählen. Die gültigen Werte sind Legacy, Standard und Windows. Das Standardverhalten ist plattformspezifisch. Auf Windows-Plattformen ist die Standardeinstellung Windows und auf Nicht-Windows-Plattformen ist sie standardmäßig Standard.

Legacy ist das historische Verhalten. Das Verhalten der Modi Windows und Standard ist identisch, mit Ausnahme, dass im Windows-Modus die Aufrufe der folgenden Dateien automatisch die Legacy-Stilargumentübergabe verwenden.

• cmd.exe
• find.exe
• cscript.exe
• wscript.exe
• sqlcmd.exe: In PowerShell 7.3.1 hinzugefügt
• Endet mit .bat
• Endet mit .cmd
• Endet mit .js
• Endet mit .vbs
• Endet mit .wsf

Wenn $PSNativeCommandArgumentPassing auf Legacy oder Standard festgelegt ist, überprüft der Parser keine diese Dateien.

Das Standardverhalten ist plattformspezifisch. Auf Windows-Plattformen ist die Standardeinstellung Windows und auf Nicht-Windows-Plattformen ist sie Standard.

Neue Verhaltensweisen, die durch diese Änderung verfügbar gemacht werden:

• In literalen oder erweiterbaren Zeichenfolgen mit eingebetteten Anführungszeichen werden die Anführungszeichen beibehalten:

  PS> $a = 'a" "b'
  PS> TestExe -echoargs $a 'c" "d' e" "f
  Arg 0 is <a" "b>
  Arg 1 is <c" "d>
  Arg 2 is <e f>
  

• Leere Zeichenfolgen als Argumente werden beibehalten:

  PS> TestExe -echoargs '' a b ''
  Arg 0 is <>
  Arg 1 is <a>
  Arg 2 is <b>
  Arg 3 is <>
  

Weitere Beispiele für das neue Verhalten finden Sie unter about_Parsing.

In PowerShell 7.3 besteht nun auch die Möglichkeit zum Nachverfolgen der Parameterbindung für native Befehle. Weitere Informationen finden Sie unter Trace-Command.

PSNativeCommandErrorActionPreference

Native Befehle geben in der Regel einen Exitcode an die aufrufende Anwendung zurück, der bei Erfolg den Wert 0 oder bei einem Fehler einen Wert ungleich 0 aufweist. Native Befehle sind derzeit jedoch kein Teil des PowerShell-Fehlerdatenstroms. Die umgeleitete stderr-Ausgabe wird nicht auf dieselbe Weise interpretiert wie der PowerShell-Fehlerdatenstrom. Viele native Befehle verwenden „stderr“ als Information oder ausführlichen Datenstrom, weshalb nur der Exitcode wichtig ist. Benutzer*innen, die in ihren Skripts mit nativen Befehlen arbeiten, müssen den Beendigungsstatus nach jedem Aufruf ähnlich wie im folgenden Beispiel überprüfen:

if ($LASTEXITCODE -ne 0) {
    throw "Command failed. See above errors for details"
}

In diesem Beispiel werden jedoch nicht alle Fälle unterstützt, in denen $? aufgrund eines Cmdlet- oder Funktionsfehlers falsch sein kann, sodass $LASTEXITCODE veraltet ist.

Dieses Feature implementiert die Einstellungsvariable $PSNativeCommandUseErrorActionPreference, die steuert, wie Fehler bei nativen Befehlen in PowerShell behandelt werden. Dadurch können Fehler bei nativen Befehlen Fehlerobjekte erzeugen, die dem PowerShell-Fehlerdatenstrom hinzugefügt werden, sodass die Ausführung des Skripts ohne zusätzliche Maßnahmen abgebrochen werden kann.

$PSNativeCommandUseErrorActionPreference ist standardmäßig auf $false festgelegt. Die Festlegung der Einstellung auf $true führt zu folgendem Verhalten:

• Bei $ErrorActionPreference = 'Stop' werden Skripts unterbrochen, wenn ein nativer Befehl einen anderen Exitcode als NULL zurückgibt.
• Bei $ErrorActionPreference = 'Continue' (Standard) erhalten Sie zwar PowerShell-Fehlermeldungen zu Fehlern bei nativen Befehlen, Skripts werden aber nicht unterbrochen.

PSNativePSPathResolution

Bei Übergabe eines PSDrive-Pfads mit Verwendung des FileSystem-Anbieters an einen nativen Befehl wird der aufgelöste Dateipfad an den nativen Pfad Befehl übergeben. Dies bedeutet, dass ein Befehl wie code temp:/test.txt jetzt wie erwartet funktioniert.

Darüber hinaus gilt unter Windows Folgendes: Wenn der Pfad mit ~ beginnt, wird dieser in den vollständigen Pfad aufgelöst und an den nativen Befehl übergeben. In beiden Fällen wird der Pfad auf die Verzeichnistrennzeichen für das jeweilige Betriebssystem normalisiert.

• Handelt es sich bei dem Pfad nicht um ein PSDrive oder ~ (unter Windows), erfolgt keine Pfadnormalisierung.
• Wird der Pfad in einfachen Anführungszeichen angegeben, wird er nicht aufgelöst und als Literal betrachtet.

PSRedirectToVariable

Wenn diese Funktion aktiviert ist, wird Unterstützung für die Umleitung auf das variable Laufwerk hinzugefügt. Mit diesem Feature können Sie Daten mithilfe der variable:name-Syntax an eine Variable umleiten. PowerShell prüft das Ziel der Umleitung und ruft Set-Variable anstelle von Out-File auf, wenn es den variablen Anbieter verwendet.

Das folgende Beispiel zeigt, wie die Umleitung der Ausgabe eines Befehls zu einer Variable funktioniert:

. {
    "Output 1"
    Write-Warning "Warning, Warning!"
    "Output 2"
} 3> variable:warnings
$warnings

Output 1
Output 2
WARNING: Warning, Warning!

PSSubsystemPluginModel

Dieses Feature aktiviert das Plug-In-Modell des Subsystems in PowerShell. Es ermöglicht das Trennen von Komponenten von System.Management.Automation.dll in einzelne Subsysteme, die sich in einer eigenen Assembly befinden. Diese Trennung reduziert den Speicherbedarf des Datenträgers der Kern-Engine von PowerShell. Zudem werden diese Komponenten zu optionalen Features für eine Minimalinstallation von PowerShell.

Derzeit wird nur das Subsystem CommandPredictor unterstützt. Dieses Subsystem wird zusammen mit dem PSReadLine-Modul zum Bereitstellen benutzerdefinierter Vorhersage-Plug-Ins verwendet. Zukünftig können Job, CommandCompleter, Remoting und andere Komponenten in Subsystemassemblys außerhalb von System.Management.Automation.dll getrennt werden.

Das experimentelle Feature enthält das neue Cmdlet Get-PSSubsystem. Dieses Cmdlet ist nur verfügbar, wenn das Feature aktiviert ist. Es gibt Informationen zu den Subsystemen zurück, die auf dem System verfügbar sind.

PSNativeWindowsTildeExpansion

Wenn diese Funktion aktiviert ist, erweitert PowerShell die Tilde ohne Anführungszeichen (~) in den aktuellen Basisordner des Benutzers, bevor native Befehle aufgerufen werden. Anhand der folgenden Beispiele wird die Funktionsweise erläutert.

Wenn die Funktion deaktiviert ist, wird die Tilde als Literalzeichenfolge an den nativen Befehl übergeben.

PS> cmd.exe /c echo ~
~

Wenn die Funktion aktiviert ist, erweitert PowerShell die Tilde, bevor sie an den nativen Befehl übergeben wird.

PS> cmd.exe /c echo ~
C:\Users\username

Diese Funktion gilt nur für Windows. Auf Nicht-Windows-Plattformen wird die Tildeerweiterung nativ verwaltet.

Diese Funktion wurde in PowerShell 7.5-preview.2 hinzugefügt.

PSSerializeJSONLongEnumAsNumber

Mit diesem Feature kann das Cmdlet ConvertTo-Json beliebige Enumerationswerte basierend auf Int64/long oder UInt64/ulong als numerischen Wert und nicht als Zeichenfolgendarstellung dieses Enumerationswerts serialisieren. Dadurch wird das Verhalten der Enumerationsserialisierung an anderen Enumerationsbasistypen ausgerichtet, bei denen das Cmdlet Enumerationen als numerischen Wert serialisiert. Verwenden Sie den Parameter EnumsAsStrings für eine Serialisierung als Zeichenfolgendarstellung.

Zum Beispiel:

# PSSerializeJSONLongEnumAsNumber disabled
@{
    Key = [System.Management.Automation.Tracing.PowerShellTraceKeywords]::Cmdlets
} | ConvertTo-Json
# { "Key": "Cmdlets" }

# PSSerializeJSONLongEnumAsNumber enabled
@{
    Key = [System.Management.Automation.Tracing.PowerShellTraceKeywords]::Cmdlets
} | ConvertTo-Json
# { "Key": 32 }

# -EnumsAsStrings to revert back to the old behaviour
@{
    Key = [System.Management.Automation.Tracing.PowerShellTraceKeywords]::Cmdlets
} | ConvertTo-Json -EnumsAsStrings
# { "Key": "Cmdlets" }