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.
Attenzione
Le funzionalità sperimentali non sono destinate all'uso nell'ambiente di produzione perché in tali funzionalità le modifiche che causano un'interruzione sono consentite. Le funzionalità sperimentali non sono ufficialmente supportate. Qualsiasi feedback e report sui bug, tuttavia, è molto gradito. È possibile registrare i problemi nel repository di origine di GitHub.
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…
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à.
Nota
Alcune funzionalità hanno requisiti di configurazione, ad esempio le variabili di preferenza, che devono essere impostate per ottenere i risultati desiderati dalla 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
PSAnsiRenderingFileInfo
Nota
Questa funzionalità è diventata mainstream in PowerShell 7.3.
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
Nota
Questa funzionalità è diventata mainstream in PowerShell 7.3.
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.
Attenzione
Il nuovo comportamento è una modifica che causa un'interruzione rispetto al comportamento corrente. Questo può interrompere gli script e l'automazione che possono risolvere i vari problemi quando si richiamano applicazioni native. Storicamente, le virgolette devono essere precedute da escape e non è possibile fornire argomenti vuoti a un'applicazione nativa.
Usare il token di arresto dell'analisi (--%) o il cmdlet per eseguire il passaggio dell'argomento Start-Process nativo quando necessario.
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.exefind.execscript.exewscript.exesqlcmd.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.
Nota
Negli esempi seguenti viene usato lo TestExe.exe strumento . È possibile eseguire la compilazione TestExe dal codice sorgente.
Vedere TestExe nel repository di origine di PowerShell.
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
Nota
Questa funzionalità è diventata mainstream in PowerShell 7.4.
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
Nota
Questa funzionalità sperimentale è stata rimossa in PowerShell 7.3 e non è più supportata.
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
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.
Commenti e suggerimenti
Presto disponibile: Nel corso del 2024 verranno gradualmente disattivati i problemi di GitHub come meccanismo di feedback per il contenuto e ciò verrà sostituito con un nuovo sistema di feedback. Per altre informazioni, vedere https://aka.ms/ContentUserFeedback.
Invia e visualizza il feedback per