Uso delle funzionalità sperimentali in PowerShell

Il supporto delle funzionalità sperimentali in PowerShell mette a disposizione un meccanismo per la coesistenza delle funzionalità sperimentali con le funzionalità stabili esistenti in PowerShell o nei moduli di PowerShell.

Una funzionalità sperimentale è quella in cui la progettazione non viene finalizzata. La funzionalità è disponibile per consentire agli utenti di testarla e offrire feedback. Dopo che una funzionalità sperimentale è stata finalizzata, le modifiche alla progettazione diventano modifiche che causano un'interruzione.

Per altre informazioni sull'abilitazione o la disabilitazione di queste funzionalità, vedere Informazioni sulle funzionalità sperimentali.

Ciclo di vita delle funzionalità sperimentali

Il cmdlet Get-ExperimentalFeature restituisce tutte le funzionalità sperimentali disponibili per PowerShell. Le funzionalità sperimentali possono provenire da moduli o dal motore di PowerShell. Le funzionalità sperimentali basate su moduli sono disponibili solo dopo l'importazione del modulo. Nell'esempio seguente PSDesiredStateConfiguration non viene caricato, quindi la PSDesiredStateConfiguration.InvokeDscResource funzionalità non è disponibile.

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…

Usare i cmdlet Enable-ExperimentalFeature e Disable-ExperimentalFeature per abilitare o disabilitare una funzionalità. Per rendere effettiva questa modifica, è necessario avviare una nuova sessione di PowerShell. Eseguire il comando seguente per abilitare la PSCommandNotFoundSuggestion funzionalità:

Enable-ExperimentalFeature PSCommandNotFoundSuggestion

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

Quando una funzionalità sperimentale diventa mainstream, non è più disponibile come funzionalità sperimentale perché la funzionalità fa ora parte del motore o del modulo di PowerShell. Ad esempio, la PSAnsiRenderingFileInfo funzionalità è diventata mainstream in PowerShell 7.3. Si ottiene automaticamente la funzionalità della funzionalità.

Quando una funzionalità sperimentale non è più disponibile in PowerShell, tale funzionalità non è più disponibile. Ad esempio, la PSNativePSPathResolution funzionalità è stata sospesa in PowerShell 7.3.

Funzionalità disponibili

Questo articolo descrive le funzionalità sperimentali disponibili e come usare ognuna di esse.

Legenda

• L'icona indica che la funzionalità sperimentale è disponibile nella versione di PowerShell
• L'icona indica la versione di PowerShell in cui la funzionalità sperimentale è diventata mainstream
• L'icona indica la versione di PowerShell in cui è stata rimossa la funzionalità sperimentale

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

PSAnsiRenderingFileInfo

Le funzionalità di formattazione ANSI sono state aggiunte in PowerShell 7.2. Questa funzionalità aggiunge il membro e abilita la $PSStyle.FileInfo colorazione di tipi di file specifici.

• $PSStyle.FileInfo.Directory - Membro predefinito per specificare il colore per le directory
• $PSStyle.FileInfo.SymbolicLink - Membro predefinito per specificare il colore per i collegamenti simbolici
• $PSStyle.FileInfo.Executable - Membro predefinito per specificare il colore per i file eseguibili.
• $PSStyle.FileInfo.Extension - Usare questo membro per definire i colori per estensioni di file diverse. Il membro extension include le estensioni per i file di archiviazione e PowerShell.

Per altre informazioni, vedere about_Automatic_Variables.

PSCommandNotFoundSuggestion

Consiglia comandi possibili in base a una ricerca di corrispondenze fuzzy dopo un errore 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

Questa funzionalità abilita il -CommandWithArgs parametro per pwsh. Questo parametro consente di eseguire un comando di PowerShell con argomenti. A differenza di -Command, questo parametro popola la $args variabile predefinita che può essere usata dal comando .

La prima stringa è il comando e le stringhe successive delimitate da spazi vuoti sono gli argomenti.

Ad esempio:

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

Nell'esempio viene prodotto l'output seguente:

arg: arg1
arg: arg2

Questa funzionalità è stata aggiunta in PowerShell 7.4-preview.2.

PSDesiredStateConfiguration.InvokeDscResource

Consente la compilazione in formato MOF nei sistemi non Windows e l'uso di Invoke-DSCResource senza Gestione configurazione locale.

A partire da PowerShell 7.2, il modulo PSDesiredStateConfiguration è stato rimosso e questa funzionalità è disabilitata per impostazione predefinita. Per abilitare questa funzionalità, è necessario installare il modulo PSDesiredStateConfiguration v2.0.5 da PowerShell Gallery e abilitare la funzionalità.

DSC v3 non dispone di questa funzionalità sperimentale. DSC v3 supporta Invoke-DSCResource solo e non usa o supporta la compilazione MOF. Per altre informazioni, vedere PowerShell Desired State Configuration v3.

PSFeedbackProvider

Quando si abilita questa funzionalità, PowerShell usa un nuovo provider di commenti e suggerimenti per inviare commenti e suggerimenti quando non è possibile trovare un comando. Il provider di feedback è estendibile e può essere implementato da moduli di terze parti. Il provider di feedback può essere usato da altri sottosistemi, ad esempio il sottosistema predictor, per fornire risultati intelliSense predittivi.

Questa funzionalità include due provider di feedback predefiniti:

• GeneralCommandErrorFeedback offre la stessa funzionalità di suggerimento esistente oggi

• UnixCommandNotFound, disponibile in Linux, fornisce commenti e suggerimenti simili a bash.

  UnixCommandNotFound funge sia da provider di feedback che da predictor. Il suggerimento del comando command-not-found viene usato sia per fornire il feedback quando non è possibile trovare il comando in un'esecuzione interattiva e per fornire risultati intelliSense predittivi per la riga di comando successiva.

Questa funzionalità è stata aggiunta in PowerShell 7.4-preview.3.

PSLoadAssemblyFromNativeCode

Espone un'API per consentire il caricamento di assembly dal codice nativo.

PSModuleAutoLoadSkipOfflineFiles

Con questa funzionalità abilitata, se PSModulePath di un utente contiene una cartella da un provider di servizi cloud, ad esempio OneDrive, PowerShell non attiva più il download di tutti i file contenuti in tale cartella. Tutti i file contrassegnati come non scaricati vengono ignorati. Gli utenti che usano provider di servizi cloud per sincronizzare i moduli tra i computer devono contrassegnare la cartella del modulo come Aggiunta o lo stato equivalente per provider diversi da OneDrive. Contrassegnare la cartella del modulo come Aggiunta garantisce che i file vengano sempre mantenuti su disco.

Questa funzionalità è stata aggiunta in PowerShell 7.4-preview.1.

PSNativeCommandArgumentPassing

Quando questa funzionalità sperimentale è abilitata per PowerShell usa la ArgumentList proprietà dell'oggetto StartProcessInfo anziché il meccanismo corrente di ricostruzione di una stringa quando si richiama un eseguibile nativo.

Questa funzionalità aggiunge una nuova $PSNativeCommandArgumentPassing variabile di preferenza che controlla questo comportamento. Questa variabile consente di selezionare il comportamento in fase di esecuzione. I valori validi sono Legacy, Standarde Windows. Il comportamento predefinito è specifico della piattaforma. Nelle piattaforme Windows l'impostazione predefinita è Windows e le piattaforme non Windows per impostazione predefinita sono Standard.

Legacy è il comportamento storico. Il comportamento di Windows e Standard la modalità sono uguali tranne, in Windows modalità, le chiamate dei file seguenti usano automaticamente l'argomento di Legacy stile passando.

• cmd.exe
• find.exe
• cscript.exe
• wscript.exe
• sqlcmd.exe - Aggiunta in PowerShell 7.3.1
• terminando con .bat
• terminando con .cmd
• terminando con .js
• terminando con .vbs
• terminando con .wsf

$PSNativeCommandArgumentPassing Se è impostato su Legacy o Standard, il parser non verifica la presenza di questi file.

Il comportamento predefinito è specifico della piattaforma. Nelle piattaforme Windows l'impostazione predefinita è Windows e le piattaforme non Windows sono Standard.

Nuovi comportamenti resi disponibili da questa modifica:

• Le stringhe letterali o espandibili con virgolette incorporate vengono mantenute:

  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>
  

• Le stringhe vuote come argomenti vengono mantenute:

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

Per altri esempi del nuovo comportamento, vedere about_Parsing.

PowerShell 7.3 ha anche aggiunto la possibilità di tracciare l'associazione dei parametri per i comandi nativi. Per altre informazioni, vedere Trace-Command.

PSNativeCommandErrorActionPreference

I comandi nativi in genere restituiscono un codice di uscita all'applicazione chiamante pari a zero per esito positivo o diverso da zero per errore. Tuttavia, i comandi nativi attualmente non partecipano al flusso di errori di PowerShell. L'output stderr reindirizzato non viene interpretato come il flusso di errori di PowerShell. Molti comandi nativi usano stderr come informazioni o flusso dettagliato, quindi solo il codice di uscita è importante. Gli utenti che usano comandi nativi negli script devono controllare lo stato di uscita dopo ogni chiamata usando un esempio simile all'esempio seguente:

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

Tuttavia, questo esempio non supporta tutti i casi in cui $? può essere false da un errore di cmdlet o di funzione, rendendo $LASTEXITCODE obsoleto.

Questa funzionalità implementa la $PSNativeCommandUseErrorActionPreference variabile preferenza che controlla la modalità di gestione degli errori dei comandi nativi in PowerShell. In questo modo, gli errori dei comandi nativi generano oggetti errore aggiunti al flusso di errore di PowerShell e possono terminare l'esecuzione dello script senza gestire in modo aggiuntivo.

$PSNativeCommandUseErrorActionPreference è impostato su $false per impostazione predefinita. Con la preferenza impostata su $true si ottiene il comportamento seguente:

• Quando $ErrorActionPreference = 'Stop', gli script si interromperanno quando un comando nativo restituisce un codice di uscita diverso da zero.
• Quando $ErrorActionPreference = 'Continue' (impostazione predefinita), verranno visualizzati messaggi di errore di PowerShell per gli errori del comando nativo, ma gli script non si interromperanno.

PSNativePSPathResolution

Se a un comando nativo viene passato un percorso PSDrive che usa il provider FileSystem, al comando nativo viene passato il percorso del file risolto. Ciò significa che un comando come code temp:/test.txt ora funziona come previsto.

Inoltre, in Windows, se il percorso inizia con ~, viene risolto nel percorso completo e passato al comando nativo. In entrambi i casi, il percorso viene normalizzato nei separatori di directory per il sistema operativo pertinente.

• Se il percorso non è un PSDrive o ~ (in Windows), la normalizzazione del percorso non si verifica
• Se il percorso è racchiuso tra virgolette singole, non viene risolto e viene considerato come valore letterale

PSRedirectToVariable

Se abilitata, questa funzionalità aggiunge il supporto per il reindirizzamento all'unità variabile. Questa funzionalità consente di reindirizzare i dati a una variabile usando la variable:name sintassi . PowerShell esamina la destinazione del reindirizzamento e se usa il provider di variabili che chiama Set-Variable anziché Out-File.

L'esempio seguente illustra come reindirizzare l'output di un comando a una variabile:

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

Output 1
Output 2
WARNING: Warning, Warning!

PSSubsystemPluginModel

Questa funzionalità abilita il modello di plug-in del sottosistema in PowerShell. La funzionalità consente di separare i componenti di System.Management.Automation.dll nei singoli sottosistemi che risiedono nel proprio assembly. Questa separazione riduce l'impronta sul disco del motore di PowerShell principale e consente a questi componenti di diventare funzionalità facoltative per un'installazione di PowerShell minima.

Attualmente è supportato solo il sottosistema CommandPredictor. Questo sottosistema viene usato insieme al modulo PSReadLine per fornire plug-in di stima personalizzati. In futuro, Job, CommandCompleter, Remoting e altri componenti potrebbero essere separati in assembly di sottosistemi all'esterno di System.Management.Automation.dll.

La funzionalità sperimentale include un nuovo cmdlet, Get-PSSubsystem. Questo cmdlet è disponibile solo quando la funzionalità è abilitata. Questo cmdlet restituisce informazioni sui sottosistemi disponibili nel sistema.

PSNativeWindowsTildeExpansion

Quando questa funzionalità è abilitata, PowerShell espande la tilde non racchiusa tra virgole (~) alla cartella home corrente dell'utente prima di richiamare i comandi nativi. Gli esempi seguenti illustrano il funzionamento della funzionalità.

Con la funzionalità disabilitata, la tilde viene passata al comando nativo come stringa letterale.

PS> cmd.exe /c echo ~
~

Con la funzionalità abilitata, PowerShell espande la tilde prima che venga passata al comando nativo.

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

Questa funzionalità si applica solo a Windows. Nelle piattaforme non Windows, l'espansione tilde viene gestita in modo nativo.

Questa funzionalità è stata aggiunta in PowerShell 7.5-preview.2.

PSSerializeJSONLongEnumAsNumber

Questa funzionalità consente al cmdlet ConvertTo-Json di serializzare tutti i valori di enumerazione basati su Int64/long o UInt64/ulong come valore numerico anziché la rappresentazione di stringa di tale valore enumerazione. In questo modo, il comportamento della serializzazione delle enumerazioni viene allineato ad altri tipi di base enumerazione in cui il cmdlet serializza le enumerazioni come valore numerico. Usare il parametro EnumsAsStrings per serializzare come rappresentazione di stringa.

Ad esempio:

# 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" }