about_Preference_Variables
Descrizione breve
Variabili che personalizzano il comportamento di PowerShell.
Descrizione lunga
PowerShell include un set di variabili che consentono di personalizzarne il comportamento. Queste variabili di preferenza funzionano come le opzioni nei sistemi basati su GUI.
Le variabili di preferenza influiscono sull'ambiente operativo PowerShell e tutti i comandi eseguiti nell'ambiente. Alcuni cmdlet includono parametri che consentono di eseguire l'override del comportamento delle preferenze per un comando specifico.
Nella tabella seguente sono elencate le variabili di preferenza e i relativi valori predefiniti.
PowerShell include le variabili di ambiente seguenti che archiviano le preferenze utente. Per altre informazioni su queste variabili di ambiente, vedere about_Environment_Variables.
$env:PSExecutionPolicyPreference
$env:PSModulePath
Nota
Le modifiche apportate alle variabili di preferenza si applicano solo nell'ambito in cui vengono apportate e tutti gli ambiti figlio. Ad esempio, è possibile limitare gli effetti della modifica di una variabile di preferenza a una singola funzione o script. Per altre informazioni, vedere about_Scopes.
Uso delle variabili di preferenza
Questo documento descrive ognuna delle variabili di preferenza.
Per visualizzare il valore corrente di una variabile di preferenza specifica, digitare il nome della variabile. Ad esempio, il comando seguente visualizza il $ConfirmPreference
valore della variabile.
$ConfirmPreference
High
Per modificare il valore di una variabile, usare un'istruzione di assegnazione. Ad esempio, l'istruzione seguente modifica il $ConfirmPreference
valore del parametro su Medium.
$ConfirmPreference = "Medium"
I valori impostati sono specifici della sessione di PowerShell corrente. Per rendere effettive le variabili in tutte le sessioni di PowerShell, aggiungerle al profilo di PowerShell. Per altre informazioni, vedere about_Profiles.
Lavorare da remoto
Quando si eseguono comandi in un computer remoto, i comandi remoti sono soggetti solo alle preferenze impostate nel client PowerShell del computer remoto. Ad esempio, quando si esegue un comando remoto, il valore della variabile del $DebugPreference
computer remoto determina il modo in cui PowerShell risponde ai messaggi di debug.
Per altre informazioni sui comandi remoti, vedere about_Remote.
$ConfirmPreference
Determina se PowerShell richiede automaticamente la conferma prima di eseguire un cmdlet o una funzione.
La $ConfirmPreference
variabile accetta uno dei ConfirmImpact
valori di enumerazione: High, Medium, Low o None.
Ai cmdlet e alle funzioni viene assegnato un rischio elevato, medio o basso.
Quando il valore della variabile è minore o uguale al rischio assegnato a un cmdlet o a una funzione, PowerShell richiede automaticamente la conferma prima di $ConfirmPreference
eseguire il cmdlet o la funzione. Per altre informazioni sull'assegnazione di un rischio ai cmdlet o alle funzioni, vedere about_Functions_CmdletBindingAttribute.
Se il valore della $ConfirmPreference
variabile è None, PowerShell non richiede mai automaticamente di eseguire un cmdlet o una funzione.
Per modificare il comportamento di conferma per tutti i cmdlet e le funzioni nella sessione, modificare $ConfirmPreference
il valore della variabile.
Per eseguire l'override di $ConfirmPreference
per un singolo comando, usare il parametro Confirm di un cmdlet o di una funzione. Per richiedere la conferma, usare -Confirm
. Per eliminare la conferma, usare -Confirm:$false
.
Valori validi di $ConfirmPreference
:
- Nessuno: PowerShell non richiede automaticamente. Per richiedere la conferma di un comando specifico, usare il parametro Confirm del cmdlet o della funzione.
- Basso: PowerShell richiede la conferma prima di eseguire cmdlet o funzioni con un rischio basso, medio o elevato.
- Medio: PowerShell richiede la conferma prima di eseguire cmdlet o funzioni con un rischio medio o elevato.
- Alto: PowerShell richiede la conferma prima di eseguire cmdlet o funzioni con un rischio elevato.
Spiegazione dettagliata
PowerShell può richiedere automaticamente la conferma prima di eseguire un'azione. Ad esempio, quando il cmdlet o la funzione influisce significativamente sul sistema per eliminare i dati o usare una quantità significativa di risorse di sistema.
Remove-Item -Path C:\file.txt
Confirm
Are you sure you want to perform this action?
Performing operation "Remove File" on Target "C:\file.txt".
[Y] Yes [A] Yes to All [N] No [L] No to All [?] Help (default is "Y"):
La stima del rischio è un attributo del cmdlet o della funzione nota come ConfirmImpact. Gli utenti non possono modificarlo.
I cmdlet e le funzioni che potrebbero rappresentare un rischio per il sistema hanno un parametro Confirm che è possibile usare per richiedere o eliminare la conferma per un singolo comando.
La maggior parte dei cmdlet e delle funzioni mantiene il valore predefinito Medium per ConfirmImpact.
$ConfirmPreference
è impostato su Alto per impostazione predefinita. Di conseguenza, è raro che i comandi promptno automaticamente la conferma quando gli utenti non specificano il parametro Confirm .
Per estendere la richiesta di conferma automatica a più cmdlet e funzioni, impostare il valore di $ConfirmPreference
su Medio o Basso.
Esempi
Questo esempio mostra l'effetto del valore predefinito della $ConfirmPreference
variabile, High. Il valore Elevato conferma solo i cmdlet e le funzioni ad alto rischio. Poiché la maggior parte dei cmdlet e delle funzioni è di medio rischio, non vengono confermate automaticamente ed Remove-Item
eliminate il file. L'aggiunta -Confirm
al comando richiede conferma all'utente.
$ConfirmPreference
High
Remove-Item -Path C:\temp1.txt
Usare -Confirm
per richiedere la conferma.
Remove-Item -Path C:\temp2.txt -Confirm
Confirm
Are you sure you want to perform this action?
Performing operation "Remove File" on Target "C:\temp2.txt".
[Y] Yes [A] Yes to All [N] No [L] No to All
[?] Help (default is "Y"):
Nell'esempio seguente viene illustrato l'effetto della modifica del valore di $ConfirmPreference
su Medium. Poiché la maggior parte dei cmdlet e delle funzioni è di medie dimensioni, vengono confermate automaticamente. Per eliminare il prompt di conferma per un singolo comando, usare il parametro Confirm con il valore $false
.
$ConfirmPreference = "Medium"
Remove-Item -Path C:\temp2.txt
Confirm
Are you sure you want to perform this action?
Performing operation "Remove File" on Target "C:\temp2.txt".
[Y] Yes [A] Yes to All [N] No [L] No to All
[?] Help (default is "Y"):
Remove-Item -Path C:\temp3.txt -Confirm:$false
$DebugPreference
Determina il modo in cui PowerShell risponde al debug dei messaggi generati da uno script, da un cmdlet o da un provider o da un Write-Debug
comando nella riga di comando.
La $DebugPreference
variabile accetta uno dei ActionPreference
valori di enumerazione: SilentlyContinue, Stop, Continue, Inquire, Ignore, Suspend o Break.
Alcuni cmdlet visualizzano messaggi di debug, che in genere sono messaggi tecnici progettati per programmatori e professionisti del supporto tecnico. Per impostazione predefinita, i messaggi di debug non vengono visualizzati, ma è possibile visualizzare i messaggi di debug modificando il valore di $DebugPreference
.
È possibile usare il parametro comune Debug di un cmdlet per visualizzare o nascondere i messaggi di debug per un comando specifico. Per altre informazioni, vedi about_CommonParameters.
I valori validi sono i seguenti:
- Interruzione : immettere il debugger quando si verifica un errore o quando viene generata un'eccezione.
- Arresta: visualizza il messaggio di debug e arresta l'esecuzione. Scrive un errore nella console.
- Richiesta: visualizza il messaggio di debug e chiede se si desidera continuare.
- Continua: visualizza il messaggio di debug e continua con l'esecuzione.
- SilentlyContinue: (Impostazione predefinita) Nessun effetto. Il messaggio di debug non viene visualizzato e l'esecuzione continua senza interruzioni.
L'aggiunta del parametro comune Debug a un comando, quando il comando è configurato per generare un messaggio di debug, modifica il valore della $DebugPreference
variabile in Continua.
Esempi
Negli esempi seguenti viene illustrato l'effetto della modifica dei valori di $DebugPreference
quando un Write-Debug
comando viene immesso nella riga di comando.
La modifica influisce su tutti i messaggi di debug, inclusi i messaggi generati da cmdlet e script. Gli esempi mostrano il parametro Debug , che visualizza o nasconde i messaggi di debug correlati a un singolo comando.
Questo esempio mostra l'effetto del valore predefinito della $DebugPreference
variabile, SilentlyContinue. Per impostazione predefinita, il Write-Debug
messaggio di debug del cmdlet non viene visualizzato e l'elaborazione continua. Quando si usa il parametro Debug , sostituisce la preferenza per un singolo comando. Viene visualizzato il messaggio di debug.
$DebugPreference
SilentlyContinue
Write-Debug -Message "Hello, World"
Write-Debug -Message "Hello, World" -Debug
DEBUG: Hello, World
In questo esempio viene illustrato l'effetto di $DebugPreference
con il valore Continue . Viene visualizzato il messaggio di debug e il comando continua a elaborare.
$DebugPreference = "Continue"
Write-Debug -Message "Hello, World"
DEBUG: Hello, World
In questo esempio viene utilizzato il parametro Debug con un valore di $false
per eliminare il messaggio per un singolo comando. Il messaggio di debug non viene visualizzato.
Write-Debug -Message "Hello, World" -Debug:$false
In questo esempio viene illustrato l'effetto dell'impostazione $DebugPreference
sul valore Stop . Viene visualizzato il messaggio di debug e il comando viene arrestato.
$DebugPreference = "Stop"
Write-Debug -Message "Hello, World"
DEBUG: Hello, World
Write-Debug : The running command stopped because the preference variable
"DebugPreference" or common parameter is set to Stop: Hello, World
At line:1 char:1
+ Write-Debug -Message "Hello, World"
In questo esempio viene utilizzato il parametro Debug con un valore di $false
per eliminare il messaggio per un singolo comando. Il messaggio di debug non viene visualizzato e l'elaborazione non viene arrestata.
Write-Debug -Message "Hello, World" -Debug:$false
In questo esempio viene illustrato l'effetto di $DebugPreference
essere impostato sul valore Di richiesta . Viene visualizzato il messaggio di debug e all'utente viene richiesto di confermare.
$DebugPreference = "Inquire"
Write-Debug -Message "Hello, World"
DEBUG: Hello, World
Confirm
Continue with this operation?
[Y] Yes [A] Yes to All [H] Halt Command [?] Help (default is "Y"):
In questo esempio viene utilizzato il parametro Debug con un valore di $false
per eliminare il messaggio per un singolo comando. Il messaggio di debug non viene visualizzato e l'elaborazione continua.
Write-Debug -Message "Hello, World" -Debug:$false
$ErrorActionPreference
Determina in che modo PowerShell risponde a un errore non irreversibile, un errore che non arresta l'elaborazione del cmdlet. Ad esempio, nella riga di comando o in uno script, un cmdlet o un provider, ad esempio gli errori generati dal Write-Error
cmdlet.
La $ErrorActionPreference
variabile accetta uno dei ActionPreference
valori di enumerazione: SilentlyContinue, Stop, Continue, Inquire, Ignore, Suspend o Break.
È possibile usare il parametro comune ErrorAction di un cmdlet per eseguire l'override della preferenza per un comando specifico.
I valori validi sono i seguenti:
- Interruzione : immettere il debugger quando si verifica un errore o quando viene generata un'eccezione.
- Continua: (impostazione predefinita) Visualizza il messaggio di errore e continua l'esecuzione.
- Ignora: elimina il messaggio di errore e continua a eseguire il comando. Il valore Ignore è destinato all'uso per ogni comando, non per l'uso come preferenza salvata. Ignore non è un valore valido per la
$ErrorActionPreference
variabile. - Richiesta: visualizza il messaggio di errore e chiede se si desidera continuare.
- SilentlyContinue: nessun effetto. Il messaggio di errore non viene visualizzato e l'esecuzione continua senza interruzioni.
- Arresta: visualizza il messaggio di errore e arresta l'esecuzione. Oltre all'errore generato, il valore Stop genera un oggetto ActionPreferenceStopException nel flusso di errori.
- Sospensione: sospende automaticamente un processo del flusso di lavoro per consentire ulteriori indagini. Dopo l'analisi, il flusso di lavoro può essere ripreso. Il valore Suspend è destinato all'uso per ogni comando, non per l'uso come preferenza salvata. Suspend non è un valore valido per la
$ErrorActionPreference
variabile.
$ErrorActionPreference
e il parametro ErrorAction non influiscono sul modo in cui PowerShell risponde agli errori irreversibili che interrompono l'elaborazione dei cmdlet. Per altre informazioni sul parametro comune ErrorAction , vedere about_CommonParameters.
Molti comandi nativi scrivono in stderr
come un flusso alternativo per informazioni aggiuntive. Questo comportamento può causare confusione quando si esaminano gli errori o le informazioni di output aggiuntive possono andare perse per l'utente se $ErrorActionPreference
è impostato su uno stato che disattiva l'output.
A partire da PowerShell 7.2, i record di errore reindirizzati dai comandi nativi, ad esempio quando si usano gli operatori di reindirizzamento (2>&1
), non vengono scritti nella $Error
variabile e la variabile di preferenza non influisce $ErrorActionPreference
sull'output reindirizzato.
PowerShell 7.3 ha aggiunto una funzionalità sperimentale che consente di controllare la modalità di gestione dei messaggi scritti in stderr
.
Per altre informazioni, vedere $PSNativeCommandUseErrorActionPreference.
Esempi
Questi esempi mostrano l'effetto dei diversi valori della $ErrorActionPreference
variabile. Il parametro ErrorAction viene usato per eseguire l'override del $ErrorActionPreference
valore.
Questo esempio mostra il $ErrorActionPreference
valore predefinito Continue. Viene generato un errore non irreversibile. Il messaggio viene visualizzato e l'elaborazione continua.
# Change the ErrorActionPreference to 'Continue'
$ErrorActionPreference = 'Continue'
# Generate a non-terminating error and continue processing the script.
Write-Error -Message 'Test Error' ; Write-Host 'Hello World'
Write-Error: Test Error
Hello World
Questo esempio mostra il $ErrorActionPreference
valore predefinito, Inquire. Viene generato un errore e viene visualizzata una richiesta di azione.
# Change the ErrorActionPreference to 'Inquire'
$ErrorActionPreference = 'Inquire'
Write-Error -Message 'Test Error' ; Write-Host 'Hello World'
Confirm
Test Error
[Y] Yes [A] Yes to All [H] Halt Command [S] Suspend [?] Help (default is "Y"):
Questo esempio mostra il $ErrorActionPreference
set su SilentlyContinue.
Il messaggio di errore viene eliminato.
# Change the ErrorActionPreference to 'SilentlyContinue'
$ErrorActionPreference = 'SilentlyContinue'
# Generate an error message
Write-Error -Message 'Test Error' ; Write-Host 'Hello World'
# Error message is suppressed and script continues processing
Hello World
In questo esempio viene illustrato il $ErrorActionPreference
set su Stop. Mostra anche l'oggetto aggiuntivo generato alla $Error
variabile.
# Change the ErrorActionPreference to 'Stop'
$ErrorActionPreference = 'Stop'
# Error message is generated and script stops processing
Write-Error -Message 'Test Error' ; Write-Host 'Hello World'
# Show the ActionPreferenceStopException and the error generated
$Error[0]
$Error[1]
Write-Error: Test Error
ErrorRecord : Test Error
WasThrownFromThrowStatement : False
TargetSite : System.Collections.ObjectModel.Collection`1[System.Management.Automation.PSObject]
Invoke(System.Collections.IEnumerable)
StackTrace : at System.Management.Automation.Runspaces.PipelineBase.Invoke(IEnumerable input)
at Microsoft.PowerShell.Executor.ExecuteCommandHelper(Pipeline tempPipeline,
Exception& exceptionThrown, ExecutionOptions options)
Message : The running command stopped because the preference variable "ErrorActionPreference" or
common parameter is set to Stop: Test Error
Data : {System.Management.Automation.Interpreter.InterpretedFrameInfo}
InnerException :
HelpLink :
Source : System.Management.Automation
HResult : -2146233087
Write-Error: Test Error
$ErrorView
Determina il formato di visualizzazione dei messaggi di errore in PowerShell.
La $ErrorView
variabile accetta uno dei ErrorView
valori di enumerazione NormalView, CategoryView o ConciseView.
I valori validi sono i seguenti:
ConciseView: (impostazione predefinita) Fornisce un messaggio di errore conciso e una visualizzazione di refactoring per i generatori di moduli avanzati. A partire da PowerShell 7.2, se l'errore proviene dalla riga di comando o da un modulo script, l'output è un messaggio di errore a riga singola. In caso contrario, viene visualizzato un messaggio di errore su più righe contenente l'errore e un puntatore all'errore che mostra dove si verifica in tale riga. Se il terminale supporta il terminale virtuale, vengono usati i codici colore ANSI per fornire l'accento colore. Il colore principale può essere modificato in
$Host.PrivateData.ErrorAccentColor
. UsareGet-Error
il cmdlet per una visualizzazione dettagliata completa dell'errore completo, incluse le eccezioni interne.ConciseView è stato aggiunto in PowerShell 7.
NormalView: visualizzazione dettagliata progettata per la maggior parte degli utenti. È costituito da una descrizione dell'errore e dal nome dell'oggetto coinvolto nell'errore.
CategoryView: vista strutturata concisa progettata per gli ambienti di produzione. Il formato è il seguente:
{Category}: ({TargetName}:{TargetType}):[{Activity}], {Reason}
Per altre informazioni sui campi in CategoryView, vedere Classe ErrorCategoryInfo.
Esempi
Questo esempio mostra come viene visualizzato un errore quando il valore di $ErrorView
è il valore predefinito , ConciseView. Get-ChildItem
viene usato per trovare una directory inesistente.
Get-ChildItem -path 'C:\NoRealDirectory'
Get-ChildItem: Can't find path 'C:\NoRealDirectory' because it doesn't exist.
Questo esempio mostra come viene visualizzato un errore quando il valore di $ErrorView
è il valore predefinito , ConciseView. Script.ps1
viene eseguito e genera un errore dall'istruzione Get-Item
.
./Script.ps1
Get-Item: C:\Script.ps1
Line |
11 | Get-Item -Path .\stuff
| ^ Can't find path 'C:\demo\stuff' because it doesn't exist.
Questo esempio mostra come viene visualizzato un errore quando il valore di $ErrorView
viene modificato in NormalView. Get-ChildItem
viene utilizzato per trovare un file inesistente.
Get-ChildItem -Path C:\nofile.txt
Get-ChildItem : Can't find path 'C:\nofile.txt' because it doesn't exist.
At line:1 char:1
+ Get-ChildItem -Path C:\nofile.txt
Questo esempio mostra come viene visualizzato lo stesso errore quando il valore di $ErrorView
viene modificato in CategoryView.
$ErrorView = "CategoryView"
Get-ChildItem -Path C:\nofile.txt
ObjectNotFound: (C:\nofile.txt:String) [Get-ChildItem], ItemNotFoundException
In questo esempio viene illustrato che il valore di influisce solo sulla visualizzazione degli $ErrorView
errori. Non modifica la struttura dell'oggetto errore archiviato nella $Error
variabile automatica. Per informazioni sulla $Error
variabile automatica, vedere about_automatic_variables.
Il comando seguente accetta l'oggetto ErrorRecord associato all'errore più recente nella matrice di errori, nell'elemento 0 e formatta le proprietà dell'oggetto in un elenco.
$Error[0] | Format-List -Property * -Force
PSMessageDetails :
Exception : System.Management.Automation.ItemNotFoundException:
Cannot find path 'C:\nofile.txt' because it does
not exist.
at System.Management.Automation.SessionStateInternal.
GetChildItems(String path, Boolean recurse, UInt32
depth, CmdletProviderContext context)
at System.Management.Automation.ChildItemCmdlet
ProviderIntrinsics.Get(String path, Boolean
recurse, UInt32 depth, CmdletProviderContext context)
at Microsoft.PowerShell.Commands.GetChildItemCommand.
ProcessRecord()
TargetObject : C:\nofile.txt
CategoryInfo : ObjectNotFound: (C:\nofile.txt:String) [Get-ChildItem],
ItemNotFoundException
FullyQualifiedErrorId : PathNotFound,
Microsoft.PowerShell.Commands.GetChildItemCommand
ErrorDetails :
InvocationInfo : System.Management.Automation.InvocationInfo
ScriptStackTrace : at <ScriptBlock>, <No file>: line 1
PipelineIterationInfo : {0, 1}
$FormatEnumerationLimit
Determina il numero di elementi enumerati inclusi in una visualizzazione. Questa variabile non influisce sugli oggetti sottostanti, ma solo sulla visualizzazione. Quando il valore di $FormatEnumerationLimit
è minore del numero di elementi enumerati, PowerShell aggiunge i puntini di sospensione (...
) per indicare gli elementi non visualizzati.
Valori validi: Numeri interi (Int32
)
Valore predefinito: 4
Esempi
In questo esempio viene illustrato come usare la $FormatEnumerationLimit
variabile per migliorare la visualizzazione degli elementi enumerati.
Il comando in questo esempio genera una tabella che elenca tutti i servizi in esecuzione nel computer in due gruppi: uno per i servizi in esecuzione e uno per i servizi arrestati . Usa un Get-Service
comando per ottenere tutti i servizi e quindi invia i risultati tramite la pipeline al cmdlet , che raggruppa i risultati in base allo Group-Object
stato del servizio.
Il risultato è una tabella che elenca lo stato nella colonna Nome e i processi nella colonna Gruppo . Per modificare le etichette di colonna, usare una tabella hash, vedere about_Hash_Tables. Per altre informazioni, vedere gli esempi in Format-Table.
Trovare il valore corrente di $FormatEnumerationLimit
.
$FormatEnumerationLimit
4
Elencare tutti i servizi raggruppati in base allo stato. Nella colonna Gruppo sono elencati al massimo quattro servizi per ogni stato perché $FormatEnumerationLimit
ha un valore pari a 4.
Get-Service | Group-Object -Property Status
Count Name Group
----- ---- -----
60 Running {AdtAgent, ALG, Ati HotKey Poller, AudioSrv...}
41 Stopped {Alerter, AppMgmt, aspnet_state, ATI Smart...}
Per aumentare il numero di elementi elencati, aumentare il valore di $FormatEnumerationLimit
a 1000. Usare Get-Service
e Group-Object
per visualizzare i servizi.
$FormatEnumerationLimit = 1000
Get-Service | Group-Object -Property Status
Count Name Group
----- ---- -----
60 Running {AdtAgent, ALG, Ati HotKey Poller, AudioSrv, BITS, CcmExec...
41 Stopped {Alerter, AppMgmt, aspnet_state, ATI Smart, Browser, CiSvc...
Usare Format-Table
con il parametro Wrap per visualizzare l'elenco dei servizi.
Get-Service | Group-Object -Property Status | Format-Table -Wrap
Count Name Group
----- ---- -----
60 Running {AdtAgent, ALG, Ati HotKey Poller, AudioSrv, BITS, CcmExec,
Client for NFS, CryptSvc, DcomLaunch, Dhcp, dmserver,
Dnscache, ERSvc, Eventlog, EventSystem, FwcAgent, helpsvc,
HidServ, IISADMIN, InoRPC, InoRT, InoTask, lanmanserver,
lanmanworkstation, LmHosts, MDM, Netlogon, Netman, Nla,
NtLmSsp, PlugPlay, PolicyAgent, ProtectedStorage, RasMan,
RemoteRegistry, RpcSs, SamSs, Schedule, seclogon, SENS,
SharedAccess, ShellHWDetection, SMT PSVC, Spooler,
srservice, SSDPSRV, stisvc, TapiSrv, TermService, Themes,
TrkWks, UMWdf, W32Time, W3SVC, WebClient, winmgmt, wscsvc,
wuauserv, WZCSVC, zzInterix}
41 Stopped {Alerter, AppMgmt, aspnet_state, ATI Smart, Browser, CiSvc,
ClipSrv, clr_optimization_v2.0.50727_32, COMSysApp,
CronService, dmadmin, FastUserSwitchingCompatibility,
HTTPFilter, ImapiService, Mapsvc, Messenger, mnmsrvc,
MSDTC, MSIServer, msvsmon80, NetDDE, NetDDEdsdm, NtmsSvc,
NVSvc, ose, RasAuto, RDSessMgr, RemoteAccess, RpcLocator,
SCardSvr, SwPrv, SysmonLog, TlntSvr, upnphost, UPS, VSS,
WmdmPmSN, Wmi, WmiApSrv, xmlprov}
$InformationPreference
La $InformationPreference
variabile consente di impostare le preferenze del flusso di informazioni che si desidera visualizzare agli utenti. In particolare, i messaggi informativi aggiunti ai comandi o agli script aggiungendo il cmdlet Write-Information . Se viene utilizzato il parametro InformationAction , il relativo valore esegue l'override del valore della $InformationPreference
variabile.
Write-Information
è stato introdotto in PowerShell 5.0.
La $InformationPreference
variabile accetta uno dei ActionPreference
valori di enumerazione: SilentlyContinue, Stop, Continue, Inquire, Ignore, Suspend o Break.
I valori validi sono i seguenti:
- Interruzione : immettere il debugger quando si scrive nel flusso informazioni.
- Stop: arresta un comando o uno script in corrispondenza di un'occorrenza del
Write-Information
comando. - Richiesta: visualizza il messaggio informativo specificato in un
Write-Information
comando, quindi chiede se si desidera continuare. - Continua: visualizza il messaggio informativo e continua l'esecuzione.
- SilentlyContinue: (Impostazione predefinita) Nessun effetto. I messaggi informativi non vengono visualizzati e lo script continua senza interruzioni.
$Log*Evento
Le variabili preferenza log*evento determinano quali tipi di eventi vengono scritti nel registro eventi di PowerShell in Visualizzatore eventi. Per impostazione predefinita, vengono registrati solo gli eventi del motore e del provider. Tuttavia, è possibile usare le variabili di preferenza Log*Event per personalizzare il log, ad esempio la registrazione degli eventi relativi ai comandi.
Le variabili di preferenza Log*Event sono le seguenti:
$LogCommandHealthEvent
: registra errori ed eccezioni nell'inizializzazione e nell'elaborazione dei comandi. Il valore predefinito è$false
(non registrato).$LogCommandLifecycleEvent
: registra l'avvio e l'arresto di comandi e pipeline di comandi e eccezioni di sicurezza nell'individuazione dei comandi. Il valore predefinito è$false
(non registrato).$LogEngineHealthEvent
: registra gli errori e gli errori delle sessioni. Il valore predefinito è$true
(registrato).$LogEngineLifecycleEvent
: registra l'apertura e la chiusura delle sessioni. Il valore predefinito è$true
(registrato).$LogProviderHealthEvent
: registra errori del provider, ad esempio errori di lettura e scrittura, errori di ricerca ed errori di chiamata. Il valore predefinito è$true
(registrato).$LogProviderLifecycleEvent
: registra l'aggiunta e la rimozione dei provider di PowerShell. Il valore predefinito è$true
(registrato). Per informazioni sui provider di PowerShell, vedere about_Providers.
Per abilitare un evento Log*, digitare la variabile con il valore $true
, ad esempio:
$LogCommandLifeCycleEvent = $true
Per disabilitare un tipo di evento, digitare la variabile con un valore , $false
ad esempio:
$LogCommandLifeCycleEvent = $false
Gli eventi abilitati sono validi solo per la console di PowerShell corrente. Per applicare la configurazione a tutte le console, salvare le impostazioni delle variabili nel profilo di PowerShell. Per altre informazioni, vedere about_Profiles.
$MaximumHistoryCount
Determina il numero di comandi salvati nella cronologia dei comandi per la sessione corrente.
Valori validi: 1 - 32768 (Int32
)
Impostazione predefinita: 4096
Per determinare il numero di comandi correnti salvati nella cronologia dei comandi, digitare:
(Get-History).Count
Per visualizzare i comandi salvati nella cronologia delle sessioni, usare il Get-History
cmdlet . Per altre informazioni, vedere about_History.
$OFS
Il separatore di campi di output (OFS) specifica il carattere che separa gli elementi di una matrice che viene convertita in una stringa.
Valori validi: qualsiasi stringa.
Impostazione predefinita: Spazio
Per impostazione predefinita, la $OFS
variabile non esiste e il separatore del file di output è uno spazio, ma è possibile aggiungere questa variabile e impostarla su qualsiasi stringa. È possibile modificare il valore di $OFS
nella sessione digitando $OFS="<value>"
.
Nota
Se si prevede il valore predefinito di uno spazio (" "
) nello script, nel modulo o nell'output di configurazione, prestare attenzione che il $OFS
valore predefinito non sia stato modificato altrove nel codice.
Esempi
Questo esempio mostra che viene usato uno spazio per separare i valori quando una matrice viene convertita in una stringa. In questo caso, una matrice di numeri interi viene archiviata in una variabile e quindi viene eseguito il cast della variabile come stringa.
$array = 1,2,3,4
[string]$array
1 2 3 4
Per modificare il separatore, aggiungere la $OFS
variabile assegnando un valore.
La variabile deve essere denominata $OFS
.
$OFS = "+"
[string]$array
1+2+3+4
Per ripristinare il comportamento predefinito, è possibile assegnare uno spazio (" "
) al valore di $OFS
o eliminare la variabile. I comandi seguenti eliminano la variabile e quindi verificano che il separatore sia uno spazio.
Remove-Variable OFS
[string]$array
1 2 3 4
$OutputEncoding
Determina il metodo di codifica dei caratteri usato da PowerShell per l'inserimento di dati in applicazioni native.
Nota
Nella maggior parte degli scenari, il valore di $OutputEncoding
deve essere allineato al valore di [Console]::InputEncoding
.
I valori validi sono i seguenti: Oggetti derivati da una classe Encoding, ad esempio ASCIIEncoding, UTF7Encoding, UTF8Encoding, UTF32Encoding e UnicodeEncoding.
Impostazione predefinita: oggetto UTF8Encoding .
Esempi
Il primo comando trova il valore di $OutputEncoding
. Poiché il valore è un oggetto di codifica, visualizzare solo la relativa proprietà EncodingName .
$OutputEncoding.EncodingName
Gli esempi rimanenti usano lo script di PowerShell seguente salvato come hexdump.ps1
per illustrare il comportamento di $OutputEncoding
.
$inputStream = [Console]::OpenStandardInput()
try {
$buffer = [byte[]]::new(1024)
$read = $inputStream.Read($buffer, 0, $buffer.Length)
Format-Hex -InputObject $buffer -Count $read
} finally {
$inputStream.Dispose()
}
Nell'esempio seguente viene illustrato come il valore café
stringa viene codificato in byte quando viene inviato tramite pipe in hexdump.ps1
creato in precedenza. Dimostra che il valore stringa viene codificato usando lo schema UTF8Encoding.
'café' | pwsh -File ./hexdump.ps1
Label: Byte[] (System.Byte[]) <28873E25>
Offset Bytes Ascii
00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
------ ----------------------------------------------- -----
0000000000000000 63 61 66 C3 A9 0D 0A caf�
Nell'esempio seguente viene illustrato come cambiano i byte quando si modifica la codifica in UnicodeEncoding.
$OutputEncoding = [System.Text.Encoding]::Unicode
'café' | pwsh -File ./hexdump.ps1
Label: Byte[] (System.Byte[]) <515A7DC3>
Offset Bytes Ascii
00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
------ ----------------------------------------------- -----
0000000000000000 FF FE 63 00 61 00 66 00 E9 00 0D 00 0A 00 ÿþc a f é � �
$ProgressPreference
Determina il modo in cui PowerShell risponde agli aggiornamenti dello stato generati da uno script, un cmdlet o un provider, ad esempio le barre di stato generate dal cmdlet Write-Progress . Il Write-Progress
cmdlet crea barre di stato che mostrano lo stato di un comando.
La $ProgressPreference
variabile accetta uno dei ActionPreference
valori di enumerazione: SilentlyContinue, Stop, Continue, Inquire, Ignore, Suspend o Break.
I valori validi sono i seguenti:
- Interruzione : immettere il debugger quando si scrive nel flusso Di stato.
- Stop: non visualizza l'indicatore di stato. Visualizza invece un messaggio di errore e arresta l'esecuzione.
- Chiedi: non visualizza l'indicatore di stato. Richiede l'autorizzazione per continuare. Se si risponde con
Y
oA
, viene visualizzata la barra di stato. - Continua: (impostazione predefinita) Visualizza la barra di stato e continua con l'esecuzione.
- SilentlyContinue: esegue il comando, ma non visualizza la barra di stato.
$PSDefaultParameterValues
Specifica i valori predefiniti per i parametri dei cmdlet e delle funzioni avanzate.
Il valore di $PSDefaultParameterValues
è una tabella hash in cui la chiave è costituita dal nome del cmdlet e dal nome del parametro separati da due punti (:
). Il valore è un valore predefinito personalizzato specificato.
$PSDefaultParameterValues
è stato introdotto in PowerShell 3.0.
Per altre informazioni su questa variabile di preferenza, vedere about_Parameters_Default_Values.
$PSEmailServer
Specifica il server di posta elettronica predefinito utilizzato per inviare messaggi di posta elettronica. Questa variabile di preferenza viene usata dai cmdlet che inviano messaggi di posta elettronica, ad esempio il cmdlet Send-MailMessage .
$PSModuleAutoloadingPreference
Abilita e disabilita l'importazione automatica dei moduli nella sessione. La $PSModuleAutoloadingPreference
variabile non esiste per impostazione predefinita. Il comportamento predefinito quando la variabile non è definita è uguale $PSModuleAutoloadingPreference = 'All'
a .
Per importare automaticamente un modulo, ottenere o usare un comando contenuto nel modulo.
La $PSModuleAutoloadingPreference
variabile accetta uno dei PSModuleAutoLoadingPreference
valori di enumerazione:
All
: i moduli vengono importati automaticamente al primo utilizzo.ModuleQualified
: i moduli vengono importati automaticamente solo quando un utente usa il nome completo del modulo di un comando nel modulo. Ad esempio, se l'utente digitaMyModule\MyCommand
, PowerShell importa il modulo MyModule .None
: disabilita l'importazione automatica dei moduli. Per importare un modulo, usare ilImport-Module
cmdlet .
Per altre informazioni sull'importazione automatica dei moduli, vedere about_Modules.
$PSNativeCommandArgumentPassing
PowerShell 7.3 ha modificato il modo in cui analizza la riga di comando per i comandi nativi.
La nuova $PSNativeCommandArgumentPassing
variabile di preferenza controlla questo comportamento.
Attenzione
Il nuovo comportamento è una modifica che causa un'interruzione rispetto al comportamento precedente. Questo può interrompere gli script e l'automazione che possono risolvere i vari problemi quando si richiamano applicazioni native.
La variabile $PSNativeCommandArgumentPassing
automatica consente di selezionare il comportamento in fase di esecuzione. I valori validi sono Legacy
, Standard
e Windows
. Legacy
è il comportamento storico.
La $PSNativeCommandArgumentPassing
variabile è definita per impostazione predefinita, ma il valore è specifico della piattaforma.
- In Windows, la preferenza è impostata su
Windows
. - Nelle piattaforme non Windows, la preferenza è impostata su
Standard
. - Se la
$PSNativeCommandArgumentPassing
variabile è stata rimossa, PowerShell usa ilStandard
comportamento.
Il comportamento di e Standard
la modalità sono uguali, ad eccezione del Windows
fatto che, in Windows
modalità, PowerShell usa il Legacy
comportamento di passaggio dell'argomento quando si eseguono i file seguenti.
cmd.exe
cscript.exe
find.exe
sqlcmd.exe
wscript.exe
- File che terminano con:
.bat
.cmd
.js
.vbs
.wsf
$PSNativeCommandArgumentPassing
Se è impostato su Legacy
o Standard
, il parser non verifica la presenza di questi file. Per 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.
$PSNativeCommandUseErrorActionPreference
Quando $PSNativeCommandUseErrorActionPreference
è $true
, i comandi nativi con codici di uscita diversi da zero rilasciano errori in base a $ErrorActionPreference
.
Alcuni comandi nativi, ad esempio robocopy , usano codici di uscita diversi da zero per rappresentare informazioni diverse da errori. In questi casi, è possibile disabilitare temporaneamente il comportamento e impedire l'emissione di errori da parte di codici di uscita diversi da zero.
& {
# Disable $PSNativeCommandUseErrorActionPreference for this scriptblock
$PSNativeCommandUseErrorActionPreference = $false
robocopy.exe D:\reports\operational "\\reporting\ops" CY2022Q4.md
if ($LASTEXITCODE -gt 8) {
throw "robocopy failed with exit code $LASTEXITCODE"
}
}
In questo esempio la $PSNativeCommandUseErrorActionPreference
variabile viene modificata all'interno di uno scriptblock. La modifica è locale per lo scriptblock. Quando lo scriptblock viene chiuso, la variabile ripristina il valore precedente.
$PSSessionApplicationName
Specifica il nome dell'applicazione predefinito per un comando remoto che usa la tecnologia Web Services for Management (WS-Management). Per altre informazioni, vedere Informazioni su Gestione remota Windows.
Il nome predefinito dell'applicazione di sistema è WSMAN
, ma è possibile usare questa variabile di preferenza per modificare il valore predefinito.
Il nome dell'applicazione è l'ultimo nodo in un URI di connessione. Ad esempio, il nome dell'applicazione nell'URI di esempio seguente è WSMAN
.
http://Server01:8080/WSMAN
Il nome dell'applicazione predefinito viene usato quando il comando remoto non specifica un URI di connessione o un nome di applicazione.
Il servizio WinRM usa il nome dell'applicazione per selezionare un listener per gestire la richiesta di connessione. Il valore del parametro deve corrispondere al valore della proprietà URLPrefix di un listener nel computer remoto.
Per eseguire l'override del valore predefinito del sistema e del valore di questa variabile e selezionare un nome di applicazione diverso per una determinata sessione, usare i parametri ConnectionURI o ApplicationName dei cmdlet New-PSSession, Enter-PSSession o Invoke-Command .
La $PSSessionApplicationName
variabile preferenza viene impostata nel computer locale, ma specifica un listener nel computer remoto. Se il nome dell'applicazione specificato non esiste nel computer remoto, il comando per stabilire la sessione non riesce.
$PSSessionConfigurationName
Specifica la configurazione di sessione predefinita usata per creare nuove sessioni nella sessione corrente.
Questa variabile di preferenza viene impostata nel computer locale, ma specifica una configurazione di sessione che si trova nel computer remoto.
Il valore della $PSSessionConfigurationName
variabile è un URI di risorsa completo.
Il valore http://schemas.microsoft.com/PowerShell/microsoft.PowerShell
predefinito indica la configurazione della sessione Microsoft.PowerShell nel computer remoto.
Se si specifica solo un nome di configurazione, viene anteporto l'URI dello schema seguente:
http://schemas.microsoft.com/PowerShell/
È possibile eseguire l'override del valore predefinito e selezionare una configurazione di sessione diversa per una determinata sessione usando il parametro ConfigurationName dei New-PSSession
cmdlet , Enter-PSSession
o Invoke-Command
.
È possibile modificare il valore di questa variabile in qualsiasi momento. Quando si esegue questa operazione, tenere presente che la configurazione di sessione selezionata deve esistere nel computer remoto. In caso contrario, il comando per creare una sessione che usa la configurazione della sessione ha esito negativo.
Questa variabile di preferenza non determina quali configurazioni di sessione locali vengono usate quando gli utenti remoti creano una sessione che si connette al computer. Tuttavia, è possibile usare le autorizzazioni per le configurazioni di sessione locali per determinare quali utenti possono usarle.
$PSSessionOption
Stabilisce i valori predefiniti per le opzioni utente avanzate in una sessione remota. Queste preferenze di opzione sostituiscono i valori predefiniti del sistema per le opzioni di sessione.
La $PSSessionOption
variabile contiene un oggetto PSSessionOption . Per altre informazioni, vedere System.Management.Automation.Remoting.PSSessionOption.
Ogni proprietà dell'oggetto rappresenta un'opzione di sessione. Ad esempio, la proprietà NoCompression trasforma la compressione dei dati durante la sessione.
Per impostazione predefinita, la $PSSessionOption
variabile contiene un oggetto PSSessionOption con i valori predefiniti per tutte le opzioni, come illustrato di seguito.
MaximumConnectionRedirectionCount : 5
NoCompression : False
NoMachineProfile : False
ProxyAccessType : None
ProxyAuthentication : Negotiate
ProxyCredential :
SkipCACheck : False
SkipCNCheck : False
SkipRevocationCheck : False
OperationTimeout : 00:03:00
NoEncryption : False
UseUTF16 : False
IncludePortInSPN : False
OutputBufferingMode : None
Culture :
UICulture :
MaximumReceivedDataSizePerCommand :
MaximumReceivedObjectSize : 209715200
ApplicationArguments :
OpenTimeout : 00:03:00
CancelTimeout : 00:01:00
IdleTimeout : -00:00:00.0010000
Per le descrizioni di queste opzioni e altre informazioni, vedere New-PSSessionOption. Per altre informazioni sui comandi e le sessioni remoti, vedere about_Remote e about_PSSessions.
Per modificare il valore della variabile di preferenza, usare il New-PSSessionOption
cmdlet per creare un oggetto PSSessionOption con i valori di $PSSessionOption
opzione che si preferisce. Salvare l'output in una variabile denominata $PSSessionOption
.
$PSSessionOption = New-PSSessionOption -NoCompression
Per usare la $PSSessionOption
variabile di preferenza in ogni sessione di PowerShell, aggiungere un New-PSSessionOption
comando che crea la $PSSessionOption
variabile al profilo di PowerShell. Per altre informazioni, vedere about_Profiles.
È possibile impostare opzioni personalizzate per una determinata sessione remota. Le opzioni impostate hanno la precedenza sulle impostazioni predefinite di sistema e sul valore della $PSSessionOption
variabile di preferenza.
Per impostare le opzioni di sessione personalizzate, usare il New-PSSessionOption
cmdlet per creare un oggetto PSSessionOption . Usare quindi l'oggetto PSSessionOption come valore del parametro SessionOption nei cmdlet che creano una sessione, ad esempio New-PSSession
, Enter-PSSession
e Invoke-Command
.
$PSStyle
A partire da PowerShell 7.2 è ora possibile accedere alla $PSStyle
variabile automatica per visualizzare e modificare il rendering dell'output della stringa ANSI. $PSStyle
è un'istanza della classe PSStyle . I membri di questa classe definiscono stringhe contenenti sequenze di escape ANSI che controllano il rendering del testo nel terminale.
I membri di base restituiscono stringhe di sequenze di escape ANSI mappate ai relativi nomi. I valori sono impostabili per consentire la personalizzazione. I nomi delle proprietà semplificano la creazione di stringhe decorate usando il completamento tramite tabulazione. Ad esempio:
"$($PSStyle.Background.BrightCyan)Power$($PSStyle.Underline)$($PSStyle.Bold)Shell$($PSStyle.Reset)"
I membri Background e Foreground hanno anche un metodo per specificare il FromRgb()
colore a 24 bit.
Per altre informazioni su $PSStyle
, vedere about_ANSI_Terminals.
$Transcript
Utilizzato da Start-Transcript
per specificare il nome e il percorso del file di trascrizione. Se non si specifica un valore per il parametro Path , Start-Transcript
usa il percorso nel valore della $Transcript
variabile globale. Se questa variabile non è stata creata, Start-Transcript
archivia le trascrizioni nel percorso seguente usando il nome predefinito:
- In Windows:
$HOME\Documents
- In Linux o macOS:
$HOME
Il nome file predefinito è: PowerShell_transcript.<computername>.<random>.<timestamp>.txt
.
$VerbosePreference
Determina in che modo PowerShell risponde ai messaggi dettagliati generati da uno script, un cmdlet o un provider, ad esempio i messaggi generati dal cmdlet Write-Verbose . I messaggi dettagliati descrivono le azioni eseguite per eseguire un comando.
Per impostazione predefinita, i messaggi dettagliati non vengono visualizzati, ma è possibile modificare questo comportamento modificando il valore di $VerbosePreference
.
La $VerbosePreference
variabile accetta uno dei ActionPreference
valori di enumerazione: SilentlyContinue, Stop, Continue, Inquire, Ignore, Suspend o Break.
I valori validi sono i seguenti:
- Interruzione : immettere il debugger quando si scrive nel flusso dettagliato.
- Stop: visualizza il messaggio dettagliato e un messaggio di errore e quindi arresta l'esecuzione.
- Richiedi: visualizza il messaggio dettagliato e quindi visualizza un prompt che chiede se continuare.
- Continua: visualizza il messaggio dettagliato e quindi continua con l'esecuzione.
- SilentlyContinue: (impostazione predefinita) Non visualizza il messaggio dettagliato. Continua l'esecuzione.
È possibile usare il parametro comune dettagliato di un cmdlet per visualizzare o nascondere i messaggi dettagliati per un comando specifico. Per altre informazioni, vedi about_CommonParameters.
Esempi
Questi esempi mostrano l'effetto dei diversi valori di $VerbosePreference
e del parametro Verbose per eseguire l'override del valore di preferenza.
Questo esempio mostra l'effetto del valore SilentlyContinue , ovvero l'impostazione predefinita. Il comando usa il parametro Message , ma non scrive un messaggio nella console di PowerShell.
Write-Verbose -Message "Verbose message test."
Quando si usa il parametro Verbose , il messaggio viene scritto.
Write-Verbose -Message "Verbose message test." -Verbose
VERBOSE: Verbose message test.
In questo esempio viene illustrato l'effetto del valore Continue . La $VerbosePreference
variabile è impostata su Continua e viene visualizzato il messaggio.
$VerbosePreference = "Continue"
Write-Verbose -Message "Verbose message test."
VERBOSE: Verbose message test.
In questo esempio viene usato il parametro Verbose con un valore di $false
che esegue l'override del valore Continue. Il messaggio non viene visualizzato.
Write-Verbose -Message "Verbose message test." -Verbose:$false
In questo esempio viene illustrato l'effetto del valore Stop . La $VerbosePreference
variabile è impostata su Stop e viene visualizzato il messaggio. Il comando viene arrestato.
$VerbosePreference = "Stop"
Write-Verbose -Message "Verbose message test."
VERBOSE: Verbose message test.
Write-Verbose : The running command stopped because the preference variable
"VerbosePreference" or common parameter is set to Stop: Verbose message test.
At line:1 char:1
+ Write-Verbose -Message "Verbose message test."
In questo esempio viene usato il parametro Verbose con un valore di $false
che esegue l'override del valore Stop. Il messaggio non viene visualizzato.
Write-Verbose -Message "Verbose message test." -Verbose:$false
In questo esempio viene illustrato l'effetto del valore Di richiesta . La $VerbosePreference
variabile è impostata su Inquire. Viene visualizzato il messaggio e all'utente viene richiesto di confermare.
$VerbosePreference = "Inquire"
Write-Verbose -Message "Verbose message test."
VERBOSE: Verbose message test.
Confirm
Continue with this operation?
[Y] Yes [A] Yes to All [H] Halt Command [?] Help (default is "Y"):
In questo esempio viene usato il parametro Verbose con un valore di $false
che esegue l'override del valore Di richiesta. L'utente non viene richiesto e il messaggio non viene visualizzato.
Write-Verbose -Message "Verbose message test." -Verbose:$false
$WarningPreference
Determina in che modo PowerShell risponde ai messaggi di avviso generati da uno script, da un cmdlet o da un provider, ad esempio i messaggi generati dal cmdlet Write-Warning .
Per impostazione predefinita, i messaggi di avviso vengono visualizzati e l'esecuzione continua, ma è possibile modificare questo comportamento modificando il valore di $WarningPreference
.
La $WarningPreference
variabile accetta uno dei ActionPreference
valori di enumerazione: SilentlyContinue, Stop, Continue, Inquire, Ignore, Suspend o Break.
I valori validi sono i seguenti:
- Interruzione : immettere il debugger quando viene scritto un messaggio di avviso.
- Arresta: visualizza il messaggio di avviso e un messaggio di errore e quindi arresta l'esecuzione.
- Richiesta: visualizza il messaggio di avviso e quindi richiede l'autorizzazione per continuare.
- Continua: (impostazione predefinita) Visualizza il messaggio di avviso e quindi continua l'esecuzione.
- SilentlyContinue: non visualizza il messaggio di avviso. Continua l'esecuzione.
È possibile usare il parametro comune WarningAction di un cmdlet per determinare in che modo PowerShell risponde agli avvisi di un determinato comando. Per altre informazioni, vedi about_CommonParameters.
Esempi
Questi esempi mostrano l'effetto dei diversi valori di $WarningPreference
.
Il parametro WarningAction esegue l'override del valore di preferenza.
In questo esempio viene illustrato l'effetto del valore predefinito Continue.
$m = "This action can delete data."
Write-Warning -Message $m
WARNING: This action can delete data.
In questo esempio viene utilizzato il parametro WarningAction con il valore SilentlyContinue per eliminare l'avviso. Il messaggio non viene visualizzato.
$m = "This action can delete data."
Write-Warning -Message $m -WarningAction SilentlyContinue
In questo esempio la $WarningPreference
variabile viene modificata nel valore SilentlyContinue . Il messaggio non viene visualizzato.
$WarningPreference = "SilentlyContinue"
$m = "This action can delete data."
Write-Warning -Message $m
In questo esempio viene usato il parametro WarningAction per arrestare quando viene generato un avviso.
$m = "This action can delete data."
Write-Warning -Message $m -WarningAction Stop
WARNING: This action can delete data.
Write-Warning : The running command stopped because the preference variable
"WarningPreference" or common parameter is set to Stop:
This action can delete data.
At line:1 char:1
+ Write-Warning -Message $m -WarningAction Stop
In questo esempio la $WarningPreference
variabile viene modificata nel valore Di richiesta . All'utente viene richiesta la conferma.
$WarningPreference = "Inquire"
$m = "This action can delete data."
Write-Warning -Message $m
WARNING: This action can delete data.
Confirm
Continue with this operation?
[Y] Yes [A] Yes to All [H] Halt Command [?] Help (default is "Y"):
In questo esempio viene usato il parametro WarningAction con il valore SilentlyContinue. Il comando continua a essere eseguito e non viene visualizzato alcun messaggio.
$m = "This action can delete data."
Write-Warning -Message $m -WarningAction SilentlyContinue
In questo esempio il $WarningPreference
valore viene modificato in Stop.
$WarningPreference = "Stop"
$m = "This action can delete data."
Write-Warning -Message $m
WARNING: This action can delete data.
Write-Warning : The running command stopped because the preference variable
"WarningPreference" or common parameter is set to Stop:
This action can delete data.
At line:1 char:1
+ Write-Warning -Message $m
In questo esempio viene utilizzata la proprietà WarningAction con il valore Di richiesta . L'utente viene richiesto quando si verifica un avviso.
$m = "This action can delete data."
Write-Warning -Message $m -WarningAction Inquire
WARNING: This action can delete data.
Confirm
Continue with this operation?
[Y] Yes [A] Yes to All [H] Halt Command [?] Help (default is "Y"):
$WhatIfPreference
Determina se WhatIf viene abilitato automaticamente per ogni comando che lo supporta. Quando WhatIf è abilitato, il cmdlet segnala l'effetto previsto del comando, ma non esegue il comando.
I valori validi sono i seguenti:
- False (0, non abilitato): (Impostazione predefinita) WhatIf non è abilitato automaticamente. Per abilitarlo manualmente, usare il parametro WhatIf del cmdlet.
- True (1, abilitato): WhatIf viene abilitato automaticamente in qualsiasi comando che lo supporta. Gli utenti possono usare il parametro WhatIf con un valore False per disabilitarlo manualmente, ad esempio
-WhatIf:$false
.
Esempi
Questi esempi mostrano l'effetto dei diversi valori di $WhatIfPreference
.
Illustrano come usare il parametro WhatIf per eseguire l'override del valore di preferenza per un comando specifico.
In questo esempio viene illustrato l'effetto della $WhatIfPreference
variabile impostata sul valore predefinito False. Usare Get-ChildItem
per verificare che il file esista.
Remove-Item
elimina il file. Dopo l'eliminazione del file, è possibile verificare l'eliminazione con Get-ChildItem
.
Get-ChildItem -Path .\test.txt
Remove-Item -Path ./test.txt
Directory: C:\Test
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a--- 9/13/2019 10:53 10 test.txt
Get-ChildItem -Path .\test.txt
Get-ChildItem : Cannot find path 'C:\Test\test.txt' because it does not exist.
At line:1 char:1
+ Get-ChildItem -File test.txt
In questo esempio viene illustrato l'effetto dell'utilizzo del parametro WhatIf quando il valore di $WhatIfPreference
è False.
Verificare che il file esista.
Get-ChildItem -Path .\test2.txt
Directory: C:\Test
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a--- 2/28/2019 17:06 12 test2.txt
Utilizzare il parametro WhatIf per determinare il risultato del tentativo di eliminazione del file.
Remove-Item -Path .\test2.txt -WhatIf
What if: Performing the operation "Remove File" on target "C:\Test\test2.txt".
Verificare che il file non sia stato eliminato.
Get-ChildItem -Path .\test2.txt
Directory: C:\Test
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a--- 2/28/2019 17:06 12 test2.txt
In questo esempio viene illustrato l'effetto della $WhatIfPreference
variabile impostata sul valore True. Quando si usa Remove-Item
per eliminare un file, viene visualizzato il percorso del file, ma il file non viene eliminato.
Tentare di eliminare un file. Viene visualizzato un messaggio su cosa accadrebbe se Remove-Item
fosse stato eseguito, ma il file non viene eliminato.
$WhatIfPreference = "True"
Remove-Item -Path .\test2.txt
What if: Performing the operation "Remove File" on target "C:\Test\test2.txt".
Usare Get-ChildItem
per verificare che il file non sia stato eliminato.
Get-ChildItem -Path .\test2.txt
Directory: C:\Test
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a--- 2/28/2019 17:06 12 test2.txt
In questo esempio viene illustrato come eliminare un file quando il valore di $WhatIfPreference
è True. Usa il parametro WhatIf con il valore .$false
Usare Get-ChildItem
per verificare che il file sia stato eliminato.
Remove-Item -Path .\test2.txt -WhatIf:$false
Get-ChildItem -Path .\test2.txt
Get-ChildItem : Cannot find path 'C:\Test\test2.txt' because it does not exist.
At line:1 char:1
+ Get-ChildItem -Path .\test2.txt
Di seguito sono riportati esempi del Get-Process
cmdlet che non supporta WhatIf e Stop-Process
che supporta WhatIf. Il $WhatIfPreference
valore della variabile è True.
Get-Process
non supporta WhatIf. Quando il comando viene eseguito, viene visualizzato il processo Winword .
Get-Process -Name Winword
NPM(K) PM(M) WS(M) CPU(s) Id SI ProcessName
------ ----- ----- ------ -- -- -----------
130 119.84 173.38 8.39 15024 4 WINWORD
Stop-Process
supporta WhatIf. Il processo Winword non viene arrestato.
Stop-Process -Name Winword
What if: Performing the operation "Stop-Process" on target "WINWORD (15024)".
È possibile eseguire l'override del Stop-Process
comportamento WhatIf usando il parametro WhatIf con il valore $false
. Il processo Winword viene arrestato.
Stop-Process -Name Winword -WhatIf:$false
Per verificare che il processo Winword sia stato arrestato, usare Get-Process
.
Get-Process -Name Winword
Get-Process : Cannot find a process with the name "Winword".
Verify the process name and call the cmdlet again.
At line:1 char:1
+ Get-Process -Name Winword