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.
Achtung
Experimentelle Features sind nicht für den Einsatz in der Produktion vorgesehen, da Auswirkungen auf die Lauffähigkeit möglich sind. Experimentelle Features werden nicht offiziell unterstützt. Wir freuen uns jedoch über Feedback und Fehlermeldungen. Sie können Probleme im GitHub-Quellrepository melden.
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…
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.
Hinweis
Einige Funktionen verfügen über Konfigurationsanforderungen, z. B. Einstellungsvariablen, die festgelegt werden müssen, um die gewünschten Ergebnisse aus der Funktion abzurufen.
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.
PSAnsiRenderingFileInfo
Hinweis
Dieses Feature hat sich in PowerShell 7.3 durchgesetzt.
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
Hinweis
Dieses Feature hat sich in PowerShell 7.3 durchgesetzt.
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.
Achtung
Das neue Verhalten stellt einen Breaking Change gegenüber dem aktuellen Verhalten dar. Dadurch kann es geschehen, dass Skripts und Automatisierungen zum Umgehen der verschiedenen Probleme beim Aufrufen nativer Anwendungen nicht mehr funktionieren. In der Vergangenheit mussten Anführungszeichen mit Escapezeichen versehen werden, und das Übergeben leerer Argumente an eine native Anwendung war nicht möglich.
Verwenden Sie das Token zum Beenden der Analyse (stop-parsing) (--%) oder das Cmdlet Start-Process, um die native Argumentübergabe bei Bedarf zu umgehen.
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.exefind.execscript.exewscript.exesqlcmd.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.
Hinweis
In den folgenden Beispielen wird das TestExe.exe-Tool verwendet. Sie können TestExe aus dem Quellcode erstellen.
Weitere Informationen finden Sie unter TestExe im PowerShell-Quellrepository.
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
Hinweis
Diese Funktion hat sich in PowerShell 7.4 durchgesetzt.
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
Hinweis
Dieses experimentelle Feature wurde in PowerShell 7.3 entfernt und wird nicht mehr unterstützt.
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.
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.
Feedback
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Issues stufenweise als Feedbackmechanismus für Inhalte abbauen und durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unter https://aka.ms/ContentUserFeedback.
Feedback senden und anzeigen für