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 Design noch nicht finalisiert wurde. 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.

Verfügbare Features

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

Legende

  • ✔️ – Gibt an, dass das experimentelle Feature in der Version von PowerShell verfügbar ist.
  • ✅ – Gibt die Version von PowerShell an, in der das experimentelle Feature zur Standardversion hinzugefügt wurde.
  • ❌ – Gibt die Version von PowerShell an, in der das experimentelle Feature entfernt wurde.
Name 7.0 7.1 7.2
PSNullConditionalOperators ✔️
PSUnixFileStat (nur Nicht-Windows) ✔️ ✔️
Microsoft.PowerShell.Utility.PSManageBreakpointsInRunspace ✔️ ✔️
PSCultureInvariantReplaceOperator ✔️
PSNotApplyErrorActionToStderr ✔️
PSImplicitRemotingBatching ✔️ ✔️
PSCommandNotFoundSuggestion ✔️ ✔️ ✔️
PSDesiredStateConfiguration.InvokeDscResource ✔️ ✔️ ✔️
PSNativePSPathResolution ✔️ ✔️
PSSubsystemPluginModel ✔️ ✔️
PSNativeCommandArgumentPassing ✔️
PSAnsiRenderingFileInfo ✔️
PSLoadAssemblyFromNativeCode ✔️

Microsoft.PowerShell.Utility.PSManageBreakpointsInRunspace

Hinweis

Dieses Feature hat sich in PowerShell 7.2 durchgesetzt.

In PowerShell 7.0 aktiviert das Experiment den Parameter BreakAll für die Cmdlets Debug-Runspace und Debug-Job, damit Benutzer entscheiden können, ob PowerShell an der aktuellen Stelle sofort unterbrechen soll, wenn ein Debugger angefügt wird.

In PowerShell 7.1 fügt dieses Experiment auch den Parameter Runspace den *-PSBreakpoint-Cmdlets hinzu.

  • Disable-PSBreakpoint
  • Enable-PSBreakpoint
  • Get-PSBreakpoint
  • Remove-PSBreakpoint
  • Set-PSBreakpoint

Der Runspace-Parameter gibt ein Runspace-Objekt an, mit dem im angegebenen Runspace mit Haltepunkt en interagiert wird.

Start-Job -ScriptBlock {
    Set-PSBreakpoint -Command Start-Sleep
    Start-Sleep -Seconds 10
}

$runspace = Get-Runspace -Id 1

$breakpoint = Get-PSBreakPoint -Runspace $runspace

In diesem Beispiel wird ein Auftrag gestartet und ein Haltepunkt ist für die Ausführung des Set-PSBreakPoint festgelegt. Der Runspace wird in einer Variablen gespeichert und mit dem Runspace-Parameter an den Get-PSBreakPoint-Befehl übergeben. Sie können dann den Haltepunkt in der $breakpoint-Variablen überprüfen.

PSAnsiRenderingFileInfo

Dieses Experiment wurde 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 diesen 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.

Hinweis

Um dieses Feature verwenden zu können, muss das experimentelle Feature PSAnsiRendering aktiviert sein.

PSCommandNotFoundSuggestion

Empfiehlt potenzielle Befehle basierend auf einer Fuzzysuche nach einer CommandNotFoundException.

PS> get
get: The term 'get' is not 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.

PSCultureInvariantReplaceOperator

Wenn der linke Operand in einer -replace-Operatoranweisung keine Zeichenfolge ist, wird dieser Operand in eine Zeichenfolge konvertiert.

Ist dieses Feature deaktiviert, führt der -replace-Operator eine Zeichenfolgenkonvertierung mit Kulturerkennung durch. Wenn Ihre Kultur beispielsweise auf „Französisch (fr)“ festgelegt ist, wird der Wert 1.2 in die Zeichenfolge 1,2 konvertiert.

PS> [cultureinfo]::CurrentCulture = 'fr'
PS> 1.2 -replace ','
12
PS> [cultureinfo]::CurrentCulture = 'en'
PS> 1.2 -replace ','
1.2

Bei aktiviertem Feature:

PS> [cultureinfo]::CurrentCulture = 'fr'
PS> 1.2 -replace ','
1.2

PSDesiredStateConfiguration.InvokeDscResource

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

In früheren Vorschauversionen von PowerShell 7.2 war dieses Feature standardmäßig aktiviert. Ab PowerShell 7.2-preview7 wurde das PSDesiredStateConfiguration-Modul entfernt, und dieses Feature ist standardmäßig deaktiviert. Um dieses Feature zu aktivieren, müssen Sie das Modul PSDesiredStateConfiguration v2.0.5 aus dem PowerShell-Katalog installieren und das Feature mit Enable-ExperimentalFeature aktivieren.

PSImplicitRemotingBatching

Hinweis

Dieses experimentelle Feature wurde in PowerShell 7.2 entfernt und wird nicht mehr unterstützt.

Dieses Feature untersucht den Befehl, der in die Shell eingegeben wurde. Wenn alle Befehle implizite Remotingproxybefehle sind, die eine einfache Pipeline bilden, werden die Befehle in einem Batch zusammengefasst und als eine einzige Remotepipeline aufgerufen.

Beispiel:

# Create remote session and import TestIMod module
$s = nsn -host remoteMachine
icm $s { ipmo 'C:\Users\user\Documents\WindowsPowerShell\Modules\TestIMod\TestIMod.psd1' }
Import-PSSession $s -mod testimod

$maxProcs = 1000
$filter = 'pwsh','powershell*','wmi*'

# Without batching, this pipeline takes approximately 12 seconds to run
Measure-Command { Get-AllProcesses -MaxCount $maxProcs | Select-Custom $filter | Group-Stuff $filter }
Days              : 0
Hours             : 0
Minutes           : 0
Seconds           : 12
Milliseconds      : 463

# But with the batching experimental feature enabled, it takes approximately 0.20 seconds
Measure-Command { Get-AllProcesses -MaxCount $maxProcs | Select-Custom $filter | Group-Stuff $filter }
Days              : 0
Hours             : 0
Minutes           : 0
Seconds           : 0
Milliseconds      : 209

Wie oben gezeigt, werden bei Aktivierung des Features für die Batcherstellung alle drei impliziten Remotingproxybefehle (Get-AllProcesses, Select-Custom, Group-Stuff) in der Remotesitzung ausgeführt, und es wird nur das Ergebnis der Pipeline an den Client zurückgegeben. Dies verringert die Datenmenge, die zwischen Client und Remotesitzung gesendet wird und reduziert außerdem den Aufwand für die Objektserialisierung und -deserialisierung.

PSLoadAssemblyFromNativeCode

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

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.

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 von Escapezeichen eingeschlossen werden, und das Übergeben leerer Argumente an eine native Anwendung war nicht möglich.

Dieses Feature fügt eine neue automatische Variable $PSNativeCommandArgumentPassing hinzu, mit der Sie das Verhalten zur Laufzeit auswählen können. Die gültigen Werte sind Legacy, Standard und Windows. Legacy ist das historische Verhalten. Die Standardeinstellung, wenn das experimentelle Feature aktiviert ist, ist das neue Standard-Verhalten.

Wenn die Präferenzvariable auf Windows festgelegt ist, verwenden die Aufrufe der folgenden Dateien automatisch die Legacy-Stilargumentübergabe.

  • cmd.exe
  • cscript.exe
  • wscript.exe
  • Endet mit .bat
  • Endet mit .cmd
  • Endet mit .js
  • Endet mit .vbs
  • Endet mit .wsf

Wenn $PSNativeArgumentPassing auf Legacy oder Standard festgelegt ist, erfolgt keine Überprüfung dieser 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 jetzt beibehalten:

    PS > $a = 'a" "b'
    PS > $PSNativeCommandArgumentPassing = "Legacy"
    PS > testexe -echoargs $a 'a" "b' a" "b
    Arg 0 is <a b>
    Arg 1 is <a b>
    Arg 2 is <a b>
    PS > $PSNativeCommandArgumentPassing = "Standard"
    PS > testexe -echoargs $a 'a" "b' a" "b
    Arg 0 is <a" "b>
    Arg 1 is <a" "b>
    Arg 2 is <a b>
    
  • Leere Zeichenfolgen als Argumente werden jetzt beibehalten:

    PS>  $PSNativeCommandArgumentPassing = "Legacy"
    PS> testexe -echoargs '' a b ''
    Arg 0 is <a>
    Arg 1 is <b>
    PS> $PSNativeCommandArgumentPassing = "Standard"
    PS> testexe -echoargs '' a b ''
    Arg 0 is <>
    Arg 1 is <a>
    Arg 2 is <b>
    Arg 3 is <>
    

Das neue Verhalten bewirkt keine Änderung bei Aufrufen, die folgendermaßen aussehen:

PS> $PSNativeCommandArgumentPassing = "Legacy"
PS> testexe -echoargs -k com:port=\\devbox\pipe\debug,pipe,resets=0,reconnect
Arg 0 is <-k>
Arg 1 is <com:port=\\devbox\pipe\debug,pipe,resets=0,reconnect>
PS> $PSNativeCommandArgumentPassing = "Standard"
PS> testexe -echoargs -k com:port=\\devbox\pipe\debug,pipe,resets=0,reconnect
Arg 0 is <-k>
Arg 1 is <com:port=\\devbox\pipe\debug,pipe,resets=0,reconnect>

Darüber hinaus steht nun Ablaufverfolgung von Parametern zur Verfügung, sodass Trace-Command nützliche Informationen für das Debuggen liefert.

PS> $PSNativeCommandArgumentPassing = "Legacy"
PS> trace-command -PSHOST -Name ParameterBinding { testexe -echoargs $a 'a" "b' a" "b }
DEBUG: 2021-02-01 17:19:53.6438 ParameterBinding Information: 0 : BIND NAMED native application line args [/Users/james/src/github/forks/jameswtruher/PowerShell-1/test/tools/TestExe/bin/testexe]
DEBUG: 2021-02-01 17:19:53.6440 ParameterBinding Information: 0 :     BIND argument [-echoargs a" "b a" "b "a b"]
DEBUG: 2021-02-01 17:19:53.6522 ParameterBinding Information: 0 : CALLING BeginProcessing
Arg 0 is <a b>
Arg 1 is <a b>
Arg 2 is <a b>
PS> $PSNativeCommandArgumentPassing = "Standard"
PS> trace-command -PSHOST -Name ParameterBinding { testexe -echoargs $a 'a" "b' a" "b }
DEBUG: 2021-02-01 17:20:01.9829 ParameterBinding Information: 0 : BIND NAMED native application line args [/Users/james/src/github/forks/jameswtruher/PowerShell-1/test/tools/TestExe/bin/testexe]
DEBUG: 2021-02-01 17:20:01.9829 ParameterBinding Information: 0 :     BIND cmd line arg [-echoargs] to position [0]
DEBUG: 2021-02-01 17:20:01.9830 ParameterBinding Information: 0 :     BIND cmd line arg [a" "b] to position [1]
DEBUG: 2021-02-01 17:20:01.9830 ParameterBinding Information: 0 :     BIND cmd line arg [a" "b] to position [2]
DEBUG: 2021-02-01 17:20:01.9831 ParameterBinding Information: 0 :     BIND cmd line arg [a b] to position [3]
DEBUG: 2021-02-01 17:20:01.9908 ParameterBinding Information: 0 : CALLING BeginProcessing
Arg 0 is <a" "b>
Arg 1 is <a" "b>
Arg 2 is <a b>

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.

PSNotApplyErrorActionToStderr

Wenn dieses experimentelle Feature aktiviert ist, werden Fehlerdatensätze, die von nativen Befehlen umgeleitet werden, wie bei der Verwendung von Umleitungsoperatoren (2>&1), nicht in die $Error-Variable geschrieben, und die Einstellungsvariable $ErrorActionPreference beeinflusst die umgeleitete Ausgabe nicht.

Viele native Befehle schreiben in stderr als alternativen Stream für weitere Informationen. Dieses Verhalten kann beim Durchsehen von Fehlern Verwirrung verursachen, oder die zusätzlichen Ausgabeinformationen können für den Benutzer verloren gehen, wenn $ErrorActionPreference auf einen Zustand festgelegt ist, der die Ausgabe unterdrückt.

Wenn ein nativer Befehl einen Exitcode ungleich 0 (null) aufweist, wird $? auf $false festgelegt. Wenn der Exitcode 0 (null) ist, wird $? auf $true festgelegt.

PSNullConditionalOperators

Hiermit werden neue Operatoren für den NULL-bedingten Memberzugriff eingeführt: ?. und ?[]. Operatoren für den NULL-Memberzugriff können für Skalar- und Arraytypen verwendet werden. Geben Sie den Wert des Members zurück, auf den zugegriffen wurde, wenn die Variable ungleich NULL ist. Lautet der Wert der Variablen NULL, geben Sie NULL zurück.

$x = $null
${x}?.propname
${x?}?.propname

${x}?[0]
${x?}?[0]

${x}?.MyMethod()

Es wird auf die Eigenschaft propname zugegriffen, und ihr Wert wird nur zurückgegeben, wenn $x nicht NULL lautet. Ähnlich wird der Indexer nur verwendet, wenn $x nicht NULL lautet. Wenn $x NULL ist, wird NULL zurückgegeben.

Die Operatoren ?. und ?[] sind Memberzugriffsoperatoren und lassen kein Leerzeichen zwischen dem Variablennamen und dem Operator zu.

Da PowerShell ? als Bestandteil des Variablennamens zulässt, muss Eindeutigkeit gewährleistet werden, wenn Operatoren ohne Leerzeichen zwischen dem Variablennamen und dem Operator verwendet werden. Zur Unterscheidung muss der Name der Variablen in {} eingeschlossen werden. Beispiel: ${x?}?.propertyName oder ${y}?[0].

Hinweis

Dieses Feature befindet sich nicht mehr in der experimentellen Phase und wird in PowerShell 7.1 und höher jetzt allgemein unterstützt.

PSUnixFileStat

Dieses Feature bietet mehr Unix-ähnliche Dateiauflistungen, indem Daten aus der Unix-API stat einbezogen werden. Es fügt eine neue Hinweiseigenschaft im Dateisystemanbieter namens UnixStat hinzu, die ein Rendering von Informationen aus der Unix-API stat(2) enthält.

Die Ausgabe von Get-ChildItem sollte ungefähr wie folgt aussehen:

dir | select -first 4 -skip 5


    Directory: /Users/jimtru/src/github/forks/JamesWTruher/PowerShell-1

UnixMode   User      Group           LastWriteTime        Size Name
--------   ----      -----           -------------        ---- ----
drwxr-xr-x jimtru    staff        10/23/2019 13:16         416 test
drwxr-xr-x jimtru    staff         11/8/2019 10:37         896 tools
-rw-r--r-- jimtru    staff         11/8/2019 10:37      112858 build.psm1
-rw-r--r-- jimtru    staff         11/8/2019 10:37      201297 CHANGELOG.md

Hinweis

Dieses Feature befindet sich nicht mehr in der experimentellen Phase und wird in PowerShell 7.1 und höher jetzt allgemein unterstützt.

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.