Använda experimentella funktioner i PowerShell

Stöd för experimentella funktioner i PowerShell är en mekanism för experimentella funktioner som kan samexistera med befintliga stabila funktioner i PowerShell- eller PowerShell-moduler.

En experimentell funktion är en funktion där designen inte har slutförts. Funktionen är tillgänglig för användare att testa och ge feedback. När en experimentell funktion har slutförts blir designändringarna icke-bakåtkompatibla.

Varning

Experimentella funktioner är inte avsedda att användas i produktion eftersom ändringarna tillåts brytas. Experimentella funktioner stöds inte officiellt. Vi uppskattar dock all feedback och buggrapporter. Du kan skapa filproblem på GitHub-källlagringsplatsen.

Mer information om hur du aktiverar eller inaktiverar dessa funktioner finns i about_Experimental_Features.

Tillgängliga funktioner

I den här artikeln beskrivs de experimentella funktioner som är tillgängliga och hur du använder funktionen.

Förklaring

• ✔️ – anger att den experimentella funktionen är tillgänglig i versionen av PowerShell
• ✅ – anger vilken version av PowerShell där den experimentella funktionen blev mainstream
• ❌ – anger vilken version av PowerShell där den experimentella funktionen togs bort

Name	7.0	7.1	7.2	7.3
PSNullConditionalOperators	✔️	✅
PSUnixFileStat (endast icke-Windows)	✔️	✔️	✅
Microsoft.PowerShell.Utility.PSManageBreakpointsInRunspace	✔️	✔️	✅
PSCultureInvariantReplaceOperator		✔️	✅
PSNotApplyErrorActionToStderr		✔️	✅
PSImplicitRemotingBatching	✔️	✔️	❌
PSCommandNotFoundSuggestion	✔️	✔️	✔️	✔️
PSDesiredStateConfiguration.InvokeDscResource	✔️	✔️	✔️	✔️
PSNativePSPathResolution		✔️	✔️	✔️
PSSubsystemPluginModel		✔️	✔️	✔️
PSNativeCommandArgumentPassing			✔️	✔️
PSAnsiRenderingFileInfo			✔️	✔️
PSLoadAssemblyFromNativeCode			✔️	✔️
PSCleanBlock				✔️
PSExec				✔️
PSNativeCommandErrorActionPreference				✔️
PSStrictModeAssignment				✔️
PSAMSIMethodInvocationLogging				✔️

Microsoft.PowerShell.Utility.PSManageBreakpointsInRunspace

Anteckning

Den här funktionen blev mainstream i PowerShell 7.2.

I PowerShell 7.0 aktiverar experimentet parametern BreakAll på Debug-Runspace cmdletarna och Debug-Job så att användarna kan avgöra om de vill att PowerShell ska brytas omedelbart på den aktuella platsen när de kopplar ett felsökningsprogram.

I PowerShell 7.1 lägger det här experimentet även till runspace-parametern i *-PSBreakpoint cmdletarna.

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

Parametern Runspace anger ett Runspace-objekt som ska interagera med brytpunkter i det angivna körningsutrymmet.

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

$runspace = Get-Runspace -Id 1

$breakpoint = Get-PSBreakPoint -Runspace $runspace

I det här exemplet startas ett jobb och en brytpunkt ställs in på att avbrytas när Set-PSBreakPoint körs. Runspace lagras i en variabel och skickas Get-PSBreakPoint till kommandot med parametern Runspace . Du kan sedan granska brytpunkten i variabeln $breakpoint .

PSAMSIMethodInvocationLogging

Amsi (Windows Antimalware Scan Interface) är ett API som gör att program kan skicka åtgärder till en skanner för program mot skadlig kod, till exempel Windows Defender, för att identifiera skadliga nyttolaster. Från och med PowerShell 5.1 skickar PowerShell som körs på Windows 10 (och högre) alla skriptblock till AMSI.

Den här experimentella funktionen utökar de data som skickas till AMSI för inspektion. Med den här funktionen aktiverad lägger PowerShell till alla anrop av .NET-metodmedlemmar.

Det här experimentet lades till i PowerShell 7.3.

Mer information om AMSI finns i Så här hjälper AMSI.

PSAnsiRenderingFileInfo

Det här experimentet lades till i PowerShell 7.2. Den här funktionen lägger till medlemmen $PSStyle.FileInfo och aktiverar färgning av specifika filtyper.

• $PSStyle.FileInfo.Directory – Inbyggd medlem för att ange färg för kataloger
• $PSStyle.FileInfo.SymbolicLink – Inbyggd medlem för att ange färg för symboliska länkar
• $PSStyle.FileInfo.Executable – Inbyggd medlem för att ange färg för körbara filer.
• $PSStyle.FileInfo.Extension – Använd den här medlemmen för att definiera färger för olika filnamnstillägg. Tilläggsmedlemmen innehåller tillägg för arkiv- och PowerShell-filer.

Mer information finns i about_Automatic_Variables.

Anteckning

Den här funktionen är beroende av psAnsiRendering-funktionen som nu är en standardfunktion.

PSCleanBlock

Blocket clean är ett praktiskt sätt för användare att rensa resurser som sträcker sig över blocken begin, processoch end . Det liknar semantiskt ett finally block som omfattar alla andra namngivna block i en skriptfunktion eller en skript-cmdlet. Resursrensning tillämpas för följande scenarier:

1. när pipelinekörningen slutförs normalt utan att felet avslutas
2. när pipelinekörningen avbryts på grund av ett avslutande fel
3. när pipelinen stoppas av Select-Object -First
4. när pipelinen stoppas av Ctrl+c eller StopProcessing()

Varning

clean Att lägga till blocket är en icke-bakåtkompatibel ändring. Eftersom clean tolkas som ett nyckelord hindrar det användare från att direkt anropa ett kommando med namnet clean som den första instruktionen i ett skriptblock. Det är dock troligtvis ett icke-problem i de flesta praktiska fall, och när det är det kan kommandot fortfarande anropas med anropsoperatorn (& clean).

Mer information om den här experimentella funktionen finns i RFC0059 i PowerShell/PowerShell-RFC-lagringsplatsen.

PSCommandNotFoundSuggestion

Rekommenderar potentiella kommandon baserat på fuzzy-matchande sökning efter en 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

När den vänstra operanden i en -replace operator-instruktion inte är en sträng konverteras operand till en sträng.

När den här funktionen är inaktiverad utför operatorn -replace en kulturkänslig strängkonvertering. Om din kultur till exempel är inställd på franska (fr) konverteras värdet 1.2 till strängen 1,2.

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

Med funktionen aktiverad:

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

PSDesiredStateConfiguration.InvokeDscResource

Möjliggör kompilering till MOF på icke-Windows-system och möjliggör användning av Invoke-DSCResource utan en LCM.

I tidigare förhandsversioner av PowerShell 7.2 aktiverades den här funktionen som standard. Från och med PowerShell 7.2-preview7 togs modulen PSDesiredStateConfiguration bort och den här funktionen är inaktiverad som standard. Om du vill aktivera den här funktionen måste du installera MODULen PSDesiredStateConfiguration v2.0.5 från PowerShell-galleriet och aktivera funktionen med .Enable-ExperimentalFeature

PSExec

Vissa inbyggda Unix-kommandon kör något (till exempel ssh) och använder det bash inbyggda kommandot exec för att skapa en ny process som ersätter den aktuella. Som standard exec är inte ett giltigt kommando i PowerShell. Detta påverkar vissa kända skript som copy-ssh-id och vissa underkommandon för AzCLI.

Den PSExec experimentella funktionen lägger till ett nytt Switch-Process cmdlet-alias till exec. Cmdleten anropar execv() funktionen för att tillhandahålla liknande beteende som POSIX-gränssnitt.

Den PSExec experimentella funktionen måste vara aktiverad för att den här cmdleten ska vara tillgänglig. Den här cmdleten är endast tillgänglig för system som inte är Windows-system.

PSImplicitRemotingBatching

Anteckning

Den här experimentella funktionen togs bort i PowerShell 7.2 och stöds inte längre.

Den här funktionen undersöker kommandot som skrivits i gränssnittet, och om alla kommandon är implicita fjärrkommunikationsproxykommandon som utgör en enkel pipeline, batchas kommandona tillsammans och anropas som en enda fjärrpipeline.

Exempel:

# 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

Som du ser ovan, med batchfunktionen aktiverad, körs alla tre implicita fjärrkommunikationsproxykommandon, Get-AllProcesses, Select-Custom, Group-Stuffi fjärrsessionen och resultatet från pipelinen är de enda data som returneras till klienten. Detta minskar mängden data som skickas fram och tillbaka mellan klient- och fjärrsessioner och minskar även mängden objektserialisering och de-serialisering.

PSLoadAssemblyFromNativeCode

Exponerar ett API för att tillåta sammansättningsinläsning från intern kod.

PSNativeCommandArgumentPassing

När den här experimentella funktionen är aktiverad använder ArgumentList PowerShell -egenskapen StartProcessInfo för objektet i stället för vår nuvarande mekanism för att rekonstruera en sträng när du anropar en intern körbar fil.

Varning

Det nya beteendet är en icke-bakåtkompatibel ändring från det aktuella beteendet. Detta kan bryta skript och automatisering som kringgår de olika problemen när inbyggda program anropas. Tidigare måste citattecken vara undantagna och det går inte att ange tomma argument till ett internt program.

Den här funktionen lägger till en ny automatisk variabel $PSNativeCommandArgumentPassing som gör att du kan välja beteendet vid körning. Giltiga värden är Legacy, Standardoch Windows. Legacy är det historiska beteendet. Standardinställningen när den experimentella funktionen är aktiverad är det nya Standard beteendet.

När inställningsvariabeln är inställd på Windowsanvänder anrop av följande filer automatiskt formatargumentet Legacy som skickas.

• cmd.exe
• cscript.exe
• wscript.exe
• slutar med .bat
• slutar med .cmd
• slutar med .js
• slutar med .vbs
• slutar med .wsf

$PSNativeArgumentPassing Om är inställt på antingen Legacy eller Standard, utförs inte kontrollen för dessa filer. Standardbeteendet är plattformsspecifikt. På Windows-plattformar är Windows standardinställningen och icke-Windows-plattformar är Standard.

Nya beteenden som görs tillgängliga genom den här ändringen:

• Literala eller expanderbara strängar med inbäddade citattecken bevaras nu:

  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>
  

• Tomma strängar som argument bevaras nu:

  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 <>
  

Det nya beteendet ändrar inte anrop som ser ut så här:

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>

Dessutom tillhandahålls nu parameterspårning, vilket Trace-Command ger användbar information för felsökning.

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>

PSNativeCommandErrorActionPreference

Interna kommandon returnerar vanligtvis en slutkod till det anropande programmet som är noll för lyckat eller icke-noll för fel. Interna kommandon deltar dock för närvarande inte i PowerShell-felströmmen. Omdirigerade stderr-utdata tolkas inte på samma sätt som PowerShell-felströmmen. Många interna kommandon använder stderr som information eller utförlig ström, vilket innebär att endast slutkoden är viktig. Användare som arbetar med interna kommandon i sina skript måste kontrollera avslutsstatusen efter varje anrop med hjälp av följande exempel:

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

Att bara vidarebefordra felen via felströmmen är inte lösningen. Exemplet i sig stöder inte alla fall där $? kan vara false från en cmdlet eller funktionsfel, vilket gör $LASTEXITCODE inaktuell.

Den här funktionen implementerar en inställningsvariabel för att aktivera fel som genereras av interna kommandon till PowerShell-fel. Detta gör att interna kommandofel kan generera felobjekt som läggs till i PowerShell-felströmmen som kan avsluta körningen av skriptet utan extra hantering.

Om du vill aktivera den här funktionen kör du följande kommandon:

Enable-ExperimentalFeature PSNativeCommandErrorActionPreference

Du måste starta en ny PowerShell-session för att den här ändringen ska gälla. I den nya sessionen måste du ange den nya inställningsvariabeln:

$PSNativeCommandUseErrorActionPreference = $true

PSNativePSPathResolution

Om en PSDrive-sökväg som använder FileSystem-providern skickas till ett internt kommando skickas den lösta filsökvägen till det interna kommandot. Det innebär att ett kommando som code temp:/test.txt nu fungerar som förväntat.

I Windows, om sökvägen börjar med ~, matchas den till den fullständiga sökvägen och skickas till det inbyggda kommandot. I båda fallen normaliseras sökvägen till katalogavgränsarna för det relevanta operativsystemet.

• Om sökvägen inte är en PSDrive eller ~ (i Windows) sker inte sökvägsnormaliseringen
• Om sökvägen finns inom enkla citattecken löses den inte och behandlas som literal

PSNotApplyErrorActionToStderr

När den här experimentella funktionen är aktiverad skrivs inte felposter som omdirigeras från interna kommandon, till exempel när du använder omdirigeringsoperatorer (2>&1), till $Error variabeln och inställningsvariabeln $ErrorActionPreference påverkar inte de omdirigerade utdata.

Många interna kommandon skriver till stderr som en alternativ ström för ytterligare information. Det här beteendet kan orsaka förvirring när du tittar igenom fel eller om ytterligare utdatainformation kan gå förlorad för användaren om $ErrorActionPreference den är inställd på ett tillstånd som stänger av utdata.

När ett internt kommando har en slutkod som inte är noll anges $? till $false. Om slutkoden är noll $? anges till $true.

PSNullConditionalOperators

Introducerar nya operatorer för null-operatorer för villkorlig medlemsåtkomst – ?. och ?[]. Null-medlemsåtkomstoperatorer kan användas för skalära typer och matristyper. Returnera värdet för den anslutna medlemmen om variabeln inte är null. Om värdet för variabeln är null returnerar du null.

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

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

${x}?.MyMethod()

Egenskapen propname används och dess värde returneras endast om $x den inte är null. På samma sätt används indexeraren endast om $x den inte är null. Om $x är null returneras null.

Operatorerna ?. och ?[] är medlemsåtkomstoperatorer och tillåter inte ett blanksteg mellan variabelnamnet och operatorn.

Eftersom PowerShell tillåter ? som en del av variabelnamnet krävs tvetydighet när operatorerna används utan blanksteg mellan variabelnamnet och operatorn. För att göra variablerna otydliga måste de användas {} runt variabelnamnet, till exempel: ${x?}?.propertyName eller ${y}?[0].

Anteckning

Den här funktionen har flyttats från den experimentella fasen och är en vanlig funktion i PowerShell 7.1 och senare.

PSStrictModeAssignment

PowerShell 7.3-preview.2 lägger till parametern StrictMode för att Invoke-Command tillåta att strikt läge anges när kommandot anropas lokalt. Parametern StrictMode anger den angivna versionen för processen. När processen är klar är StrictMode-versionen inställd på vad den var före Invoke-Command.

Den här funktionen stöder inte asynkrona jobb på fjärrdatorer.

PSUnixFileStat

Den här funktionen ger fler Unix-liknande fillistor genom att inkludera data från Unix stat-API :et. Den lägger till en ny anteckningsegenskap i filsystemprovidern unixstat som innehåller en återgivning av information från Unix-API stat(2) :et.

Utdata från Get-ChildItem bör se ut ungefär så här:

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

Anteckning

Den här funktionen har flyttats från den experimentella fasen och är en vanlig funktion i PowerShell 7.1 och senare.

PSSubsystemPluginModel

Den här funktionen aktiverar plugin-modellen för undersystemet i PowerShell. Funktionen gör det möjligt att separera komponenter i System.Management.Automation.dll enskilda undersystem som finns i deras egen sammansättning. Den här separationen minskar diskavtrycket för powershell-kärnmotorn och gör att dessa komponenter kan bli valfria funktioner för en minimal PowerShell-installation.

För närvarande stöds endast CommandPredictor-undersystemet . Det här undersystemet används tillsammans med PSReadLine-modulen för att tillhandahålla anpassade förutsägelse-plugin-program. I framtiden kan Job, CommandCompleter, Remoting och andra komponenter separeras i undersystemsammansättningar utanför System.Management.Automation.dll.

Den experimentella funktionen innehåller en ny cmdlet, Get-PSSubsystem. Den här cmdleten är bara tillgänglig när funktionen är aktiverad. Den här cmdleten returnerar information om de undersystem som är tillgängliga i systemet.