about_Preference_Variables

Description courte

Variables qui personnalisent le comportement de PowerShell.

Description longue

PowerShell inclut un ensemble de variables qui vous permettent de personnaliser son comportement. Ces variables de préférence fonctionnent comme les options des systèmes basés sur l’interface utilisateur graphique.

Les variables de préférence affectent l’environnement d’exploitation PowerShell et toutes les commandes s’exécutent dans l’environnement. Dans de nombreux cas, les applets de commande ont des paramètres que vous pouvez utiliser pour remplacer le comportement de préférence pour une commande spécifique.

Le tableau suivant répertorie les variables de préférence et leurs valeurs par défaut.

Variable Valeur par défaut
$ConfirmPreference High
$DebugPreference SilentlyContinue
$ErrorActionPreference Continue
$ErrorView ConciseView
$FormatEnumerationLimit 4
$InformationPreference SilentlyContinue
$LogCommandHealthEvent $False (non journalisé)
$LogCommandLifecycleEvent $False (non journalisé)
$LogEngineHealthEvent $True (journalisé)
$LogEngineLifecycleEvent $True (journalisé)
$LogProviderLifecycleEvent $True (journalisé)
$LogProviderHealthEvent $True (journalisé)
$MaximumHistoryCount 4096
$OFS Espace (" ")
$OutputEncoding l'objet UTF8Encoding
$ProgressPreference Continue
$PSDefaultParameterValues @{} (table de hachage vide)
$PSEmailServer $Null (aucun)
$PSModuleAutoLoadingPreference All
$PSSessionApplicationName 'wsman'
$PSSessionConfigurationName 'http://schemas.microsoft.com/powershell/Microsoft.PowerShell'
$PSSessionOption l'objet PSSessionOption
$Transcript $Null (aucun)
$VerbosePreference SilentlyContinue
$WarningPreference Continue
$WhatIfPreference $False

PowerShell inclut les variables d’environnement suivantes qui stockent les préférences utilisateur. Pour plus d’informations sur ces variables d’environnement, consultez about_Environment_Variables.

  • env:PSExecutionPolicyPreference
  • $env:PSModulePath

Notes

Les modifications apportées à la variable de préférence ne prennent effet dans les scripts et les fonctions que si ces scripts ou fonctions sont définis dans la même étendue que l’étendue dans laquelle la préférence a été utilisée. Pour plus d’informations, consultez about_Scopes.

Utilisation des variables de préférence

Ce document décrit chacune des variables de préférence.

Pour afficher la valeur actuelle d’une variable de préférence spécifique, tapez le nom de la variable. Par exemple, la commande suivante affiche la valeur de la $ConfirmPreference variable.

 $ConfirmPreference
High

Pour modifier la valeur d’une variable, utilisez une instruction d’affectation. Par exemple, l’instruction suivante remplace la $ConfirmPreference valeur du paramètre par Moyenne.

$ConfirmPreference = "Medium"

Les valeurs que vous définissez sont spécifiques à la session PowerShell actuelle. Pour rendre les variables efficaces dans toutes les sessions PowerShell, ajoutez-les à votre profil PowerShell. Pour plus d’informations, consultez about_Profiles.

Télétravail

Lorsque vous exécutez des commandes sur un ordinateur distant, les commandes distantes sont uniquement soumises aux préférences définies dans le client PowerShell de l’ordinateur distant. Par exemple, lorsque vous exécutez une commande à distance, la valeur de la variable de $DebugPreference l’ordinateur distant détermine la façon dont PowerShell répond aux messages de débogage.

Pour plus d’informations sur les commandes à distance, consultez about_Remote.

$ConfirmPreference

Détermine si PowerShell vous invite automatiquement à confirmer avant d’exécuter une applet de commande ou une fonction.

La $ConfirmPreference variable prend l’une ConfirmImpact des valeurs d’énumération : High, Medium, Low ou None.

Les applets de commande et les fonctions sont affectées à un risque élevé, moyen ou faible. Lorsque la valeur de la $ConfirmPreference variable est inférieure ou égale au risque affecté à une applet de commande ou à une fonction, PowerShell vous invite automatiquement à confirmer avant d’exécuter l’applet de commande ou la fonction.

Si la valeur de la $ConfirmPreference variable est None, PowerShell ne vous invite jamais automatiquement avant d’exécuter une applet de commande ou une fonction.

Pour modifier le comportement de confirmation pour toutes les applets de commande et fonctions de la session, modifiez $ConfirmPreference la valeur de la variable.

Pour remplacer le pour une commande unique, utilisez le $ConfirmPreference paramètre Confirm d’une applet de commande ou d’une fonction. Pour demander une confirmation, utilisez -Confirm. Pour supprimer la confirmation, utilisez -Confirm:$false.

Valeurs valides de $ConfirmPreference:

  • Aucun : PowerShell ne vous invite pas automatiquement. Pour demander la confirmation d’une commande particulière, utilisez le paramètre Confirm de l’applet de commande ou de la fonction .
  • Faible : PowerShell demande une confirmation avant d’exécuter des applets de commande ou des fonctions avec un risque faible, moyen ou élevé.
  • Moyen : PowerShell demande une confirmation avant d’exécuter des applets de commande ou des fonctions avec un risque moyen ou élevé.
  • Élevé : PowerShell demande une confirmation avant d’exécuter des applets de commande ou des fonctions présentant un risque élevé.

Explication détaillée

PowerShell peut vous demander automatiquement une confirmation avant d’effectuer une action. Par exemple, lorsque l’applet de commande ou la fonction affecte considérablement le système pour supprimer des données ou utiliser une quantité importante de ressources système.

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"):

L’estimation du risque est un attribut de l’applet de commande ou de la fonction appelée ConfirmImpact. Les utilisateurs ne peuvent pas le changer.

Les applets de commande et les fonctions qui peuvent présenter un risque pour le système ont un paramètre Confirm que vous pouvez utiliser pour demander ou supprimer la confirmation pour une seule commande.

Étant donné que la plupart des applets de commande et des fonctions utilisent la valeur de risque par défaut ConfirmImpact de Moyenne et que la valeur par défaut de $ConfirmPreference est Élevée, la confirmation automatique se produit rarement. Toutefois, vous pouvez activer la confirmation automatique en remplaçant la valeur de $ConfirmPreference par Moyen ou Faible.

Exemples

Cet exemple montre l’effet de la valeur par défaut de la $ConfirmPreference variable, High. La valeur élevée confirme uniquement les applets de commande et les fonctions à haut risque. Étant donné que la plupart des applets de commande et des fonctions présentent un risque moyen, elles ne sont pas automatiquement confirmées et Remove-Item suppriment le fichier. L’ajout -Confirm à la commande invite l’utilisateur à confirmer.

$ConfirmPreference
High
Remove-Item -Path C:\temp1.txt

Utilisez -Confirm pour demander une confirmation.

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"):

L’exemple suivant montre l’effet de la modification de la valeur de $ConfirmPreference par Moyen. Étant donné que la plupart des applets de commande et des fonctions présentent un risque moyen, elles sont automatiquement confirmées. Pour supprimer l’invite de $falseconfirmation d’une commande unique, utilisez le paramètre Confirm avec la valeur .

$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

Détermine la façon dont PowerShell répond aux messages de débogage générés par un script, une applet de commande ou un fournisseur, ou par une Write-Debug commande sur la ligne de commande.

La $DebugPreference variable prend l’une ActionPreference des valeurs d’énumération : SilentlyContinue, Stop, Continue, Inquire, Ignore, Suspend ou Break.

Certaines applets de commande affichent des messages de débogage, qui sont généralement des messages techniques conçus pour les programmeurs et les professionnels du support technique. Par défaut, les messages de débogage ne sont pas affichés, mais vous pouvez afficher les messages de débogage en modifiant la valeur de $DebugPreference.

Vous pouvez utiliser le paramètre commun Debug d’une applet de commande pour afficher ou masquer les messages de débogage d’une commande spécifique. Pour plus d’informations, consultez about_CommonParameters.

Les valeurs valides sont les suivantes :

  • Arrêter : affiche le message de débogage et arrête l’exécution. Écrit une erreur dans la console.
  • Inquire : affiche le message de débogage et vous demande si vous souhaitez continuer. L’ajout du paramètre commun Debug à une commande, lorsque la commande est configurée pour générer un message de débogage, remplace la valeur de la $DebugPreference variable par Inquire.
  • Continuer : affiche le message de débogage et poursuit l’exécution.
  • SilentlyContinue : (Par défaut) Aucun effet. Le message de débogage n’est pas affiché et l’exécution se poursuit sans interruption.

Exemples

Les exemples suivants montrent l’effet de la modification des valeurs de $DebugPreference lorsqu’une Write-Debug commande est entrée sur la ligne de commande. La modification affecte tous les messages de débogage, y compris les messages générés par les applets de commande et les scripts. Les exemples montrent le paramètre Debug , qui affiche ou masque les messages de débogage liés à une seule commande.

Cet exemple montre l’effet de la valeur par défaut de la $DebugPreference variable, SilentlyContinue. Par défaut, le message de débogage de l’applet Write-Debug de commande n’est pas affiché et le traitement se poursuit. Lorsque le paramètre Debug est utilisé, il remplace la préférence pour une seule commande. Le message de débogage s’affiche.

$DebugPreference
SilentlyContinue
Write-Debug -Message "Hello, World"
Write-Debug -Message "Hello, World" -Debug
DEBUG: Hello, World

Cet exemple montre l’effet de $DebugPreference avec la valeur Continue . Le message de débogage s’affiche et la commande continue de traiter.

$DebugPreference = "Continue"
Write-Debug -Message "Hello, World"
DEBUG: Hello, World

Cet exemple utilise le paramètre Debug avec la valeur de $false pour supprimer le message d’une commande unique. Le message de débogage n’est pas affiché.

Write-Debug -Message "Hello, World" -Debug:$false

Cet exemple montre l’effet d’être $DebugPreference défini sur la valeur Stop . Le message de débogage s’affiche et la commande est arrêtée.

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

Cet exemple utilise le paramètre Debug avec la valeur de $false pour supprimer le message d’une commande unique. Le message de débogage n’est pas affiché et le traitement n’est pas arrêté.

Write-Debug -Message "Hello, World" -Debug:$false

Cet exemple montre l’effet d’être $DebugPreference défini sur la valeur Inquire . Le message de débogage s’affiche et l’utilisateur est invité à confirmer.

$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"):

Cet exemple utilise le paramètre Debug avec la valeur de $false pour supprimer le message d’une commande unique. Le message de débogage n’est pas affiché et le traitement continue.

Write-Debug -Message "Hello, World" -Debug:$false

$ErrorActionPreference

Détermine la façon dont PowerShell répond à une erreur de non-fin, une erreur qui n’arrête pas le traitement de l’applet de commande. Par exemple, sur la ligne de commande ou dans un script, une applet de commande ou un fournisseur, comme les erreurs générées par l’applet de Write-Error commande.

La $ErrorActionPreference variable prend l’une ActionPreference des valeurs d’énumération : SilentlyContinue, Stop, Continue, Inquire, Ignore, Suspend ou Break.

Vous pouvez utiliser le paramètre commun ErrorAction d’une applet de commande pour remplacer la préférence pour une commande spécifique.

Les valeurs valides sont les suivantes :

  • Arrêt : entrez le débogueur lorsqu’une erreur se produit ou lorsqu’une exception est levée.
  • Continuer : (Par défaut) Affiche le message d’erreur et continue l’exécution.
  • Ignorer : supprime le message d’erreur et continue d’exécuter la commande. La valeur Ignorer est destinée à une utilisation par commande, et non à une utilisation en tant que préférence enregistrée. Ignorer n’est pas une valeur valide pour la $ErrorActionPreference variable.
  • Se renseigner : affiche le message d’erreur et vous demande si vous souhaitez continuer.
  • SilencieuxContinue : aucun effet. Le message d’erreur n’est pas affiché et l’exécution se poursuit sans interruption.
  • Arrêter : affiche le message d’erreur et arrête l’exécution. En plus de l’erreur générée, la valeur Stop génère un objet ActionPreferenceStopException dans le flux d’erreurs.
  • Suspendre : interrompt automatiquement un travail de flux de travail pour permettre une investigation plus approfondie. Après examen, le flux de travail peut être repris. La valeur Suspend est destinée à une utilisation par commande, et non à une utilisation en tant que préférence enregistrée. Suspendre n’est pas une valeur valide pour la $ErrorActionPreference variable.

$ErrorActionPreference et le paramètre ErrorAction n’affectent pas la façon dont PowerShell répond aux erreurs de fin qui arrêtent le traitement de l’applet de commande. Pour plus d’informations sur le paramètre commun ErrorAction , consultez about_CommonParameters.

Exemples

Ces exemples montrent l’effet des différentes valeurs de la $ErrorActionPreference variable. Le paramètre ErrorAction est utilisé pour remplacer la $ErrorActionPreference valeur.

Cet exemple montre la $ErrorActionPreference valeur par défaut Continue. Une erreur de non-fin est générée. Le message s’affiche et le traitement se poursuit.

# 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

Cet exemple montre la $ErrorActionPreference valeur par défaut , Inquire. Une erreur est générée et une invite d’action s’affiche.

# 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"):

Cet exemple montre la $ErrorActionPreference valeur définie sur SilentlyContinue. Le message d’erreur est supprimé.

# 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

Cet exemple montre le $ErrorActionPreference paramètre défini sur Arrêter. Il montre également l’objet supplémentaire généré pour la $Error variable.

# Change the ErrorActionPreference to 'Stop'
$ErrorActionPreference = 'Stop'
# Error message is 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

Détermine le format d’affichage des messages d’erreur dans PowerShell.

La $ErrorView variable prend l’une ErrorView des valeurs d’énumération : NormalView, CategoryView ou ConciseView.

Les valeurs valides sont les suivantes :

  • ConciseView : (par défaut) Fournit un message d’erreur concis et une vue refactorisée pour les générateurs de modules avancés. À partir de PowerShell 7.2, si l’erreur provient de la ligne de commande ou d’un module de script, la sortie est un message d’erreur à une seule ligne. Sinon, vous recevez un message d’erreur multiligne qui contient l’erreur et un pointeur vers l’erreur montrant où elle se produit dans cette ligne. Si le terminal prend en charge le terminal virtuel, les codes de couleur ANSI sont utilisés pour fournir un accent de couleur. La couleur Accentuation peut être modifiée dans $Host.PrivateData.ErrorAccentColor. Utilisez l’applet Get-Error de commande pour obtenir une vue détaillée complète de l’erreur complète, y compris les exceptions internes.

    ConciseView a été ajouté dans PowerShell 7.

  • NormalView : vue détaillée conçue pour la plupart des utilisateurs. Se compose d’une description de l’erreur et du nom de l’objet impliqué dans l’erreur.

  • CategoryView : vue succincte et structurée conçue pour les environnements de production. au format suivant :

    {Category}: ({TargetName}:{TargetType}):[{Activity}], {Reason}

Pour plus d’informations sur les champs dans CategoryView, consultez Classe ErrorCategoryInfo .

Exemples

Cet exemple montre comment une erreur apparaît lorsque la valeur de $ErrorView est conciseView par défaut. Get-ChildItem est utilisé pour rechercher un répertoire inexistant.

Get-ChildItem -path 'C:\NoRealDirectory'
Get-ChildItem: Cannot find path 'C:\NoRealDirectory' because it does not exist.

Cet exemple montre comment une erreur apparaît lorsque la valeur de $ErrorView est conciseView par défaut. Script.ps1 est exécuté et lève une erreur à partir de l’instruction Get-Item .

./Script.ps1
Get-Item: C:\Script.ps1
Line |
  11 | Get-Item -Path .\stuff
     | ^ Cannot find path 'C:\demo\stuff' because it does not exist.

Cet exemple montre comment une erreur s’affiche lorsque la valeur de $ErrorView est modifiée en NormalView. Get-ChildItem est utilisé pour rechercher un fichier inexistant.

Get-ChildItem -Path C:\nofile.txt
Get-ChildItem : Cannot find path 'C:\nofile.txt' because it does not exist.
At line:1 char:1
+ Get-ChildItem -Path C:\nofile.txt

Cet exemple montre comment la même erreur s’affiche lorsque la valeur de $ErrorView est modifiée en CategoryView.

$ErrorView = "CategoryView"
Get-ChildItem -Path C:\nofile.txt
ObjectNotFound: (C:\nofile.txt:String) [Get-ChildItem], ItemNotFoundException

Cet exemple montre que la valeur de $ErrorView affecte uniquement l’affichage de l’erreur. Cela ne modifie pas la structure de l’objet d’erreur stocké dans la $Error variable automatique. Pour plus d’informations sur la $Error variable automatique, consultez about_automatic_variables.

La commande suivante prend l’objet ErrorRecord associé à l’erreur la plus récente dans le tableau d’erreurs, élément 0, et met en forme les propriétés de l’objet dans une liste.

$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

Détermine le nombre d’éléments énumérés inclus dans un affichage. Cette variable n’affecte pas les objets sous-jacents, mais uniquement l’affichage. Lorsque la valeur de $FormatEnumerationLimit est inférieure au nombre d’éléments énumérés, PowerShell ajoute des points de suspension (...) pour indiquer les éléments non affichés.

Valeurs valides : Entiers (Int32)

Valeur par défaut : 4

Exemples

Cet exemple montre comment utiliser la $FormatEnumerationLimit variable pour améliorer l’affichage des éléments énumérés.

La commande de cet exemple génère une table qui répertorie tous les services exécutés sur l’ordinateur dans deux groupes : l’un pour l’exécution des services et l’autre pour les services arrêtés . Il utilise une Get-Service commande pour obtenir tous les services, puis envoie les résultats via le pipeline à l’applet Group-Object de commande, qui regroupe les résultats par état du service.

Le résultat est une table qui répertorie l’état dans la colonne Nom et les processus dans la colonne Groupe . Pour modifier les étiquettes de colonne, utilisez une table de hachage, consultez about_Hash_Tables. Pour plus d’informations, consultez les exemples dans Format-Table.

Recherchez la valeur actuelle de $FormatEnumerationLimit.

$FormatEnumerationLimit
4

Répertoriez tous les services regroupés par État. Il existe un maximum de quatre services répertoriés dans la colonne Groupe pour chaque état, car $FormatEnumerationLimit a la valeur 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...}

Pour augmenter le nombre d’éléments répertoriés, augmentez la valeur de $FormatEnumerationLimità 1000. Utilisez Get-Service et Group-Object pour afficher les services.

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

Utilisez Format-Table avec le paramètre Wrap pour afficher la liste des services.

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 variable vous permet de définir les préférences de flux d’informations que vous souhaitez afficher aux utilisateurs. Plus précisément, les messages d’information que vous avez ajoutés aux commandes ou aux scripts en ajoutant l’applet de commande Write-Information . Si le paramètre InformationAction est utilisé, sa valeur remplace la valeur de la $InformationPreference variable. Write-Information a été introduit dans PowerShell 5.0.

La $InformationPreference variable prend l’une ActionPreference des valeurs d’énumération : SilentlyContinue, Stop, Continue, Inquire, Ignore, Suspend ou Break.

Les valeurs valides sont les suivantes :

  • Arrêter : arrête une commande ou un script à une occurrence de la Write-Information commande.
  • Se renseigner : affiche le message d’information que vous spécifiez dans une Write-Information commande, puis vous demande si vous souhaitez continuer.
  • Continuer : affiche le message d’information et continue son exécution.
  • La suspension est disponible uniquement pour les workflows qui ne sont pas pris en charge dans PowerShell 6 et versions ultérieures.
  • SilentlyContinue : (Valeur par défaut) Aucun effet. Les messages d’information ne s’affichent pas et le script continue sans interruption.

$Log*Événement

Les variables de préférence d’événement Log*déterminent les types d’événements qui sont écrits dans le journal des événements PowerShell dans observateur d'événements. Par défaut, seuls les événements de moteur et de fournisseur sont consignés. Toutefois, vous pouvez utiliser les variables de préférence Log*Event pour personnaliser votre journal, comme la journalisation des événements relatifs aux commandes.

Les variables de préférence Log*Event sont les suivantes :

  • $LogCommandHealthEvent: consigne les erreurs et exceptions dans l’initialisation et le traitement des commandes. La valeur par défaut est $false (non journalisée).
  • $LogCommandLifecycleEvent: journalise le démarrage et l’arrêt des commandes et des pipelines de commandes et des exceptions de sécurité dans la découverte de commandes. La valeur par défaut est $false (non journalisée).
  • $LogEngineHealthEvent: consigne les erreurs et les échecs des sessions. La valeur par défaut est $true (journalisé).
  • $LogEngineLifecycleEvent: journalise l’ouverture et la fermeture des sessions. La valeur par défaut est $true (journalisé).
  • $LogProviderHealthEvent: journalise les erreurs du fournisseur, telles que les erreurs de lecture et d’écriture, les erreurs de recherche et les erreurs d’appel. La valeur par défaut est $true (journalisé).
  • $LogProviderLifecycleEvent: journaux d’ajout et de suppression de fournisseurs PowerShell. La valeur par défaut est $true (journalisé). Pour plus d’informations sur les fournisseurs PowerShell, consultez about_Providers.

Pour activer un événement Log*, tapez la variable avec la valeur $true, par exemple :

$LogCommandLifeCycleEvent = $true

Pour désactiver un type d’événement, tapez la variable avec la valeur $false, par exemple :

$LogCommandLifeCycleEvent = $false

Les événements que vous activez sont effectifs uniquement pour la console PowerShell actuelle. Pour appliquer la configuration à toutes les consoles, enregistrez les paramètres de variable dans votre profil PowerShell. Pour plus d’informations, consultez about_Profiles.

$MaximumHistoryCount

Détermine le nombre de commandes enregistrées dans l’historique des commandes pour la session active.

Valeurs valides : 1 - 32768 (Int32)

Valeur par défaut : 4096

Pour déterminer le nombre de commandes actuellement enregistrées dans l’historique des commandes, tapez :

(Get-History).Count

Pour afficher les commandes enregistrées dans votre historique de session, utilisez l’applet de Get-History commande . Pour plus d’informations, consultez about_History.

$OFS

Le séparateur de champ de sortie (OFS) spécifie le caractère qui sépare les éléments d’un tableau converti en chaîne.

Valeurs valides : n’importe quelle chaîne.

Valeur par défaut : Espace

Par défaut, la $OFS variable n’existe pas et le séparateur de fichier de sortie est un espace, mais vous pouvez ajouter cette variable et la définir sur n’importe quelle chaîne. Vous pouvez modifier la valeur de $OFS dans votre session en tapant $OFS="<value>".

Notes

Si vous attendez la valeur par défaut d’un espace (" ") dans votre script, module ou sortie de configuration, veillez à ce que la $OFS valeur par défaut n’ait pas été modifiée ailleurs dans votre code.

Exemples

Cet exemple montre qu’un espace est utilisé pour séparer les valeurs lorsqu’un tableau est converti en chaîne. Dans ce cas, un tableau d’entiers est stocké dans une variable, puis la variable est castée sous forme de chaîne.

$array = 1,2,3,4
[string]$array
1 2 3 4

Pour modifier le séparateur, ajoutez la $OFS variable en lui affectant une valeur. La variable doit être nommée $OFS.

$OFS = "+"
[string]$array
1+2+3+4

Pour restaurer le comportement par défaut, vous pouvez affecter un espace (" ") à la valeur de $OFS ou supprimer la variable. Les commandes suivantes suppriment la variable, puis vérifient que le séparateur est un espace.

Remove-Variable OFS
[string]$array
1 2 3 4

$OutputEncoding

Détermine la méthode d’encodage de caractères utilisée par PowerShell lorsqu’il envoie du texte à d’autres applications.

Par exemple, si une application retourne des chaînes Unicode à PowerShell, vous devrez peut-être remplacer la valeur par UnicodeEncoding pour envoyer les caractères correctement.

Les valeurs valides sont les suivantes : Objets dérivés d’une classe Encoding, telles que ASCIIEncoding, UTF7Encoding, UTF8Encoding, UTF32Encoding et UnicodeEncoding.

Valeur par défaut : objet UTF8Encoding .

Exemples

Cet exemple montre comment faire fonctionner la commande Windows findstr.exe dans PowerShell sur un ordinateur localisé pour une langue qui utilise des caractères Unicode, comme le chinois.

La première commande recherche la valeur de $OutputEncoding. Étant donné que la valeur est un objet d’encodage, affichez uniquement sa propriété EncodingName .

$OutputEncoding.EncodingName

Dans cet exemple, une findstr.exe commande est utilisée pour rechercher deux caractères chinois présents dans le Test.txt fichier. Lorsque cette findstr.exe commande est exécutée dans l’invite de commandes Windows (cmd.exe), findstr.exe recherche les caractères dans le fichier texte. Toutefois, lorsque vous exécutez la même findstr.exe commande dans PowerShell, les caractères sont introuvables, car powerShell les envoie dans findstr.exe du texte ASCII, au lieu de texte Unicode.

findstr <Unicode-characters>

Pour que la commande fonctionne dans PowerShell, définissez la valeur de $OutputEncoding sur la valeur de la propriété OutputEncoding de la console, en fonction des paramètres régionaux sélectionnés pour Windows. Étant donné que OutputEncoding est une propriété statique de la console, utilisez deux-points (::) dans la commande.

$OutputEncoding = [console]::OutputEncoding
$OutputEncoding.EncodingName
OEM United States

Une fois le changement d’encodage modifié, la findstr.exe commande recherche les caractères Unicode.

findstr <Unicode-characters>
test.txt:         <Unicode-characters>

$ProgressPreference

Détermine la façon dont PowerShell répond aux mises à jour de progression générées par un script, une applet de commande ou un fournisseur, telles que les barres de progression générées par l’applet de commande Write-Progress . L’applet Write-Progress de commande crée des barres de progression qui indiquent l’état d’une commande.

La $ProgressPreference variable prend l’une ActionPreference des valeurs d’énumération : SilentlyContinue, Stop, Continue, Inquire, Ignore, Suspend ou Break.

Les valeurs valides sont les suivantes :

  • Arrêter : n’affiche pas la barre de progression. Au lieu de cela, il affiche un message d’erreur et cesse de s’exécuter.
  • Se renseigner : n’affiche pas la barre de progression. Demande l’autorisation de continuer. Si vous répondez avec Y ou A, la barre de progression s’affiche.
  • Continuer : (Par défaut) Affiche la barre de progression et continue l’exécution.
  • SilencieuxContinue : exécute la commande, mais n’affiche pas la barre de progression.

$PSDefaultParameterValues

Spécifie les valeurs par défaut pour les paramètres des applets de commande et des fonctions avancées. La valeur de est une table de $PSDefaultParameterValues hachage où la clé se compose du nom de l’applet de commande et du nom du paramètre séparés par un signe deux-points (:). La valeur est une valeur par défaut personnalisée que vous spécifiez.

$PSDefaultParameterValues a été introduit dans PowerShell 3.0.

Pour plus d’informations sur cette variable de préférence, consultez about_Parameters_Default_Values.

$PSEmailServer

Spécifie le serveur de messagerie par défaut utilisé pour envoyer des messages électroniques. Cette variable de préférence est utilisée par les applets de commande qui envoient des e-mails, telles que l’applet de commande Send-MailMessage .

$PSModuleAutoloadingPreference

Active et désactive l’importation automatique de modules dans la session. Tout est la valeur par défaut. Pour importer un module, obtenez ou utilisez une commande dans le module. Par exemple, utilisez Get-Command. La $PSModuleAutoloadingPreference variable n’existe pas par défaut. Le comportement par défaut lorsque la variable n’est pas définie est le même que $PSModuleAutoloadingPreference = 'All'.

Quelle que soit la valeur de la variable, vous pouvez utiliser Import-Module pour importer un module.

La $PSModuleAutoloadingPreference variable prend l’un desPSModuleAutoLoadingPreference valeurs d’énumération : None, ModuleQualified ou All.

Les valeurs autorisées sont :

  • Tous : les modules sont importés automatiquement lors de la première utilisation.
  • ModuleQualified : les modules sont importés automatiquement uniquement lorsqu’un utilisateur utilise le nom qualifié de module d’une commande dans le module. Par exemple, si l’utilisateur tape MyModule\MyCommand, PowerShell importe le module MyModule .
  • Aucun : l’importation automatique de modules est désactivée dans la session. Pour importer un module, utilisez l’applet de Import-Module commande .

Pour plus d’informations sur l’importation automatique de modules, consultez about_Modules.

$PSNativeCommandArgumentPassing

Notes

$PSNativeCommandArgumentPassing était une fonctionnalité expérimentale devenue standard dans PowerShell 7.3. Pour plus d’informations, consultez Utilisation de fonctionnalités expérimentales.

PowerShell utilise la ArgumentList propriété de l’objet StartProcessInfo plutôt que de reconstruire une chaîne lors de l’appel d’un exécutable natif.

Attention

Le nouveau comportement est un changement cassant par rapport au comportement actuel. Il peut interrompre les scripts et l’automatisation qui contournent les différents problèmes pendant l’appel d’applications natives. Jusqu’ici, les guillemets devaient être échappés et il n’était pas possible de fournir des arguments vides à une application native.

La variable $PSNativeCommandArgumentPassing automatique vous permet de sélectionner le comportement au moment de l’exécution. Les valeurs valides sont Legacy, Standard et Windows. Legacy est le comportement historique. La valeur par défaut lorsque la fonctionnalité expérimentale est activée est le nouveau comportement Standard.

Lorsque la variable de préférence est définie sur Windows les appels des fichiers suivants, utilisez automatiquement l’argument de Legacy style passant.

  • cmd.exe
  • cscript.exe
  • wscript.exe
  • se terminant par .bat
  • se terminant par .cmd
  • se terminant par .js
  • se terminant par .vbs
  • se terminant par .wsf

Si $PSNativeArgumentPassing est défini sur Legacy ou Standard, la vérification de ces fichiers ne se produit pas. Le comportement par défaut est propre à la plateforme. Sur les plateformes Windows, le paramètre par défaut est Windows et Standard sur les plateformes non-Windows.

Nouveaux comportements mis à disposition par ce changement :

  • Les chaînes littérales ou extensibles avec des guillemets incorporés sont maintenant conservées :

    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>
    
  • Les chaînes vides en tant qu’arguments sont maintenant conservées :

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

Le nouveau comportement ne change pas les appels qui ressemblent à ceci :

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>

Par ailleurs, le suivi des paramètres étant maintenant fourni, Trace-Command donne des informations utiles pour le débogage.

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>

$PSNativeCommandUseErrorActionPreference

Cette variable de préférence est disponible dans PowerShell 7.3 et versions ultérieures avec la PSNativeCommandErrorActionPreference fonctionnalité activée.

Lorsque cette fonctionnalité est activée, les commandes natives avec des codes de sortie différents de zéro émettent des erreurs en fonction de $ErrorActionPreference quand $PSNativeCommandUseErrorActionPreference est $true.

Notes

PSNativeCommandUseErrorActionPreference est une fonctionnalité expérimentale ajoutée dans PowerShell 7.3. Pour plus d’informations, consultez Utilisation de fonctionnalités expérimentales.

$PSSessionApplicationName

Spécifie le nom d’application par défaut d’une commande distante qui utilise la technologie Web Services for Management (WS-Management). Pour plus d’informations, consultez À propos de la gestion à distance Windows.

Le nom de l’application par défaut du système est WSMAN, mais vous pouvez utiliser cette variable de préférence pour modifier la valeur par défaut.

Le nom de l’application est le dernier nœud d’un URI de connexion. Par exemple, le nom de l’application dans l’exemple d’URI suivant est WSMAN.

http://Server01:8080/WSMAN

Le nom d’application par défaut est utilisé lorsque la commande distante ne spécifie pas d’URI de connexion ou de nom d’application.

Le service WinRM utilise le nom de l’application pour sélectionner un écouteur pour traiter la demande de connexion. La valeur du paramètre doit correspondre à la valeur de la propriété URLPrefix d’un écouteur sur l’ordinateur distant.

Pour remplacer la valeur par défaut du système et la valeur de cette variable, et sélectionner un autre nom d’application pour une session particulière, utilisez les paramètres ConnectionURI ou ApplicationName des applets de commande New-PSSession, Enter-PSSession ou Invoke-Command .

La $PSSessionApplicationName variable de préférence est définie sur l’ordinateur local, mais elle spécifie un écouteur sur l’ordinateur distant. Si le nom de l’application que vous spécifiez n’existe pas sur l’ordinateur distant, la commande permettant d’établir la session échoue.

$PSSessionConfigurationName

Spécifie la configuration de session par défaut utilisée pour les sessions PSSession créées dans la session active.

Cette variable de préférence est définie sur l’ordinateur local, mais elle spécifie une configuration de session qui se trouve sur l’ordinateur distant.

La valeur de la $PSSessionConfigurationName variable est un URI de ressource complet.

La valeur http://schemas.microsoft.com/PowerShell/microsoft.PowerShell par défaut indique le Microsoft. Configuration de session PowerShell sur l’ordinateur distant.

Si vous spécifiez uniquement un nom de configuration, l’URI de schéma suivant est ajouté :

http://schemas.microsoft.com/PowerShell/

Vous pouvez remplacer la valeur par défaut et sélectionner une autre configuration de session pour une session particulière à l’aide du paramètre ConfigurationName des applets de New-PSSessioncommande , Enter-PSSessionou Invoke-Command .

Vous pouvez modifier la valeur de cette variable à tout moment. Dans ce cas, n’oubliez pas que la configuration de session que vous sélectionnez doit exister sur l’ordinateur distant. Si ce n’est pas le cas, la commande permettant de créer une session qui utilise la configuration de session échoue.

Cette variable de préférence ne détermine pas quelles configurations de session locales sont utilisées lorsque les utilisateurs distants créent une session qui se connecte à cet ordinateur. Toutefois, vous pouvez utiliser les autorisations pour les configurations de session locales pour déterminer quels utilisateurs peuvent les utiliser.

$PSSessionOption

Établit les valeurs par défaut pour les options utilisateur avancées dans une session distante. Ces préférences d’option remplacent les valeurs par défaut système pour les options de session.

La $PSSessionOption variable contient un objet PSSessionOption . Pour plus d’informations, consultez System.Management.Automation.Remoting.PSSessionOption. Chaque propriété de l’objet représente une option de session. Par exemple, la propriété NoCompression active la compression des données pendant la session.

Par défaut, la $PSSessionOption variable contient un objet PSSessionOption avec les valeurs par défaut pour toutes les options, comme indiqué ci-dessous.

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

Pour obtenir une description de ces options et plus d’informations, consultez New-PSSessionOption. Pour plus d’informations sur les sessions et les commandes à distance, consultez about_Remote et about_PSSessions.

Pour modifier la valeur de la $PSSessionOption variable de préférence, utilisez l’applet de New-PSSessionOption commande pour créer un objet PSSessionOption avec les valeurs d’option de votre choix. Enregistrez la sortie dans une variable appelée $PSSessionOption.

$PSSessionOption = New-PSSessionOption -NoCompression

Pour utiliser la variable de $PSSessionOption préférence dans chaque session PowerShell, ajoutez une New-PSSessionOption commande qui crée la $PSSessionOption variable à votre profil PowerShell. Pour plus d’informations, consultez about_Profiles.

Vous pouvez définir des options personnalisées pour une session à distance particulière. Les options que vous définissez sont prioritaires par rapport aux valeurs par défaut système et à la valeur de la $PSSessionOption variable de préférence.

Pour définir des options de session personnalisées, utilisez l’applet New-PSSessionOption de commande pour créer un objet PSSessionOption . Ensuite, utilisez l’objet PSSessionOption comme valeur du paramètre SessionOption dans les applets de commande qui créent une session, telles que New-PSSession, Enter-PSSessionet Invoke-Command.

$PSStyle

À partir de PowerShell 7.2, vous pouvez désormais accéder à la $PSStyle variable automatique pour afficher et modifier le rendu de la sortie de chaîne ANSI. La variable contient les propriétés suivantes :

  • Réinitialiser : désactive toutes les décorations
  • Blink : active Blink
  • BlinkOff : désactive Blink
  • Gras : active la mise en gras
  • BoldOff : désactive la mise en gras
  • Masqué : active Masqué
  • HiddenOff - Désactive masqué
  • Inverser : active l’option Inverse
  • ReverseOff : désactive l’option Reverse
  • Italique - Devient italique sur
  • ItalicOff - Désactive l’italique
  • Soulignement : met en évidence la mise en évidence
  • SoulignementOff : désactive la mise en évidence
  • OutputRendering : contrôle lorsque le rendu de sortie est utilisé
  • Arrière-plan : objet imbriqué pour contrôler la coloration d’arrière-plan
  • Premier plan : objet imbriqué pour contrôler la coloration de premier plan
  • Mise en forme : objet imbriqué qui contrôle la mise en forme par défaut pour les flux de sortie
  • Progression : objet imbriqué qui contrôle le rendu des barres de progression
  • FileInfo : objet imbriqué (expérimental) pour contrôler la coloration des objets FileInfo .

Les membres de base retournent des chaînes de séquences d’échappement ANSI mappées à leurs noms. Les valeurs peuvent être définies de façon à autoriser la personnalisation. Par exemple, vous pouvez remplacer l’gras par souligné. Les noms de propriétés facilitent la création de chaînes décorées à l’aide de la saisie semi-automatique de tabulation :

"$($PSStyle.Background.BrightCyan)Power$($PSStyle.Underline)$($PSStyle.Bold)Shell$($PSStyle.Reset)"

Les membres suivants contrôlent comment et quand la mise en forme ANSI est utilisée :

  • $PSStyle.OutputRendering est une System.Management.Automation.OutputRendering énumération avec les valeurs :

    • ANSI : ANSI est toujours transmis en l’emplacement.

      Important

      Vous devez utiliser le mode ANSI lors de la redirection de la sortie vers un fichier ou le pipeline destiné à être exécuté en aval. Cela garantit que la sortie n’est pas modifiée. L’utilisation de tout autre mode modifie la sortie en supprimant les séquences d’échappement ANSI, ce qui peut modifier le comportement d’exécution.

    • Texte brut : les séquences d’échappement ANSI sont toujours supprimées afin qu’il ne s’agit que de texte brut.

    • Hôte : il s’agit du comportement par défaut. Les séquences d’échappement ANSI sont supprimées dans une sortie redirigée ou redirigée.

  • Les $PSStyle.Background membres et $PSStyle.Foreground sont des chaînes qui contiennent les séquences d’échappement ANSI pour les 16 couleurs de console standard.

    • Noir
    • BrightBlack
    • White
    • BrightWhite
    • Rouge
    • BrightRed
    • Magenta
    • BrightMagenta
    • Bleu
    • BrightBlue
    • Cyan
    • BrightCyan
    • Vert
    • BrightGreen
    • Yellow
    • BrightYellow

    Les valeurs peuvent être définies et peuvent contenir n’importe quel nombre de séquences d’échappement ANSI. Il existe également une FromRgb() méthode pour spécifier une couleur 24 bits. Il existe deux façons d’appeler la FromRgb() méthode .

    • string FromRgb(byte red, byte green, byte blue)
    • string FromRgb(int rgb)

    L’un des exemples suivants définit la couleur d’arrière-plan beige 24 bits.

    $PSStyle.Background.FromRgb(245, 245, 220)
    $PSStyle.Background.FromRgb(0xf5f5dc)
    
  • $PSStyle.Formatting est un objet imbriqué pour contrôler la mise en forme par défaut des messages de débogage, d’erreur, de détail et d’avertissement. Vous pouvez également contrôler des attributs tels que la mise en gras et la mise en avant. Il remplace $Host.PrivateData comme moyen de gérer les couleurs pour la mise en forme du rendu. $Host.PrivateData continue d’exister pour la compatibilité descendante, mais n’est pas connecté à $PSStyle.Formatting.

  • $PSStyle.Progress vous permet de contrôler le rendu de la barre d’affichage de progression.

    • Style : chaîne ANSI définissant le style de rendu.
    • MaxWidth : définit la largeur maximale de la vue. Défini sur 0 pour la largeur de la console. La valeur par défaut est 120
    • Affichage : énumération avec des valeurs et MinimalClassic. Classic est le rendu existant sans modification. Minimal est le rendu minimal à une seule ligne. Minimal est la valeur par défaut.
    • UseOSCIndicator : la valeur par défaut est $false. Définissez cette valeur $true sur pour les terminaux qui prennent en charge les indicateurs OSC.

    Notes

    Si l’hôte ne prend pas en charge le terminal virtuel, $PSStyle.Progress.View est automatiquement défini sur Classic.

    L’exemple suivant définit le style de rendu sur une barre de progression minimale.

    $PSStyle.Progress.View = Minimal
    

$PSStyle.FileInfo est un objet imbriqué pour contrôler la coloration des objets FileInfo .

  • Répertoire - Membre intégré pour spécifier la couleur des répertoires
  • SymbolicLink : membre intégré pour spécifier la couleur des liens symboliques
  • Exécutable : membre intégré pour spécifier la couleur des exécutables.
  • Extension : utilisez ce membre pour définir des couleurs pour différentes extensions de fichier. Le membre Extension préintègre des extensions pour les fichiers d’archive et PowerShell.

Notes

$PSStyle.FileInfo est disponible uniquement lorsque la PSAnsiRenderingFileInfo fonctionnalité expérimentale est activée. Pour plus d’informations, consultez about_Experimental_Features et Utilisation de fonctionnalités expérimentales.

Dans PowerShell 7.3, la PSAnsiRenderingFileInfo fonctionnalité est devenue standard et disponible par défaut.

$Transcript

Utilisé par Start-Transcript pour spécifier le nom et l’emplacement du fichier de transcription. Si vous ne spécifiez pas de valeur pour le paramètre Path , Start-Transcript utilisez le chemin d’accès dans la valeur de la $Transcript variable globale. Si vous n’avez pas créé cette variable, Start-Transcript stocke les transcriptions dans le répertoire sous forme $HOME\My Documents de \PowerShell_transcript.<time-stamp>.txt fichiers.

$VerbosePreference

Détermine la façon dont PowerShell répond aux messages détaillés générés par un script, une applet de commande ou un fournisseur, tels que les messages générés par l’applet de commande Write-Verbose . Les messages détaillés décrivent les actions effectuées pour exécuter une commande.

Par défaut, les messages détaillés ne sont pas affichés, mais vous pouvez modifier ce comportement en modifiant la valeur de $VerbosePreference.

La $VerbosePreference variable prend l’une ActionPreference des valeurs d’énumération : SilentlyContinue, Stop, Continue, Inquire, Ignore, Suspend ou Break.

Les valeurs valides sont les suivantes :

  • Arrêter : affiche le message détaillé et un message d’erreur, puis arrête l’exécution.
  • Se renseigner : affiche le message détaillé, puis affiche une invite qui vous demande si vous souhaitez continuer.
  • Continuer : affiche le message détaillé, puis poursuit l’exécution.
  • SilentlyContinue : (Valeur par défaut) N’affiche pas le message détaillé. Continue l’exécution.

Vous pouvez utiliser le paramètre commun Verbose d’une applet de commande pour afficher ou masquer les messages détaillés d’une commande spécifique. Pour plus d’informations, consultez about_CommonParameters.

Exemples

Ces exemples montrent l’effet des différentes valeurs de $VerbosePreference et du paramètre Verbose pour remplacer la valeur de préférence.

Cet exemple montre l’effet de la valeur SilentlyContinue , qui est la valeur par défaut. La commande utilise le paramètre Message , mais n’écrit pas de message dans la console PowerShell.

Write-Verbose -Message "Verbose message test."

Lorsque le paramètre Verbose est utilisé, le message est écrit.

Write-Verbose -Message "Verbose message test." -Verbose
VERBOSE: Verbose message test.

Cet exemple montre l’effet de la valeur Continuer . La $VerbosePreference variable est définie sur Continuer et le message s’affiche.

$VerbosePreference = "Continue"
Write-Verbose -Message "Verbose message test."
VERBOSE: Verbose message test.

Cet exemple utilise le paramètre Verbose avec une valeur de $false qui remplace la valeur Continue . Le message n’est pas affiché.

Write-Verbose -Message "Verbose message test." -Verbose:$false

Cet exemple montre l’effet de la valeur Stop . La $VerbosePreference variable est définie sur Arrêter et le message s’affiche. La commande est arrêtée.

$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."

Cet exemple utilise le paramètre Verbose avec une valeur de $false qui remplace la valeur Stop . Le message n’est pas affiché.

Write-Verbose -Message "Verbose message test." -Verbose:$false

Cet exemple montre l’effet de la valeur Inquire . La $VerbosePreference variable est définie sur Inquire. Le message s’affiche et l’utilisateur est invité à confirmer.

$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"):

Cet exemple utilise le paramètre Verbose avec une valeur de $false qui remplace la valeur Inquire . L’utilisateur n’est pas invité et le message n’est pas affiché.

Write-Verbose -Message "Verbose message test." -Verbose:$false

$WarningPreference

Détermine la façon dont PowerShell répond aux messages d’avertissement générés par un script, une applet de commande ou un fournisseur, tels que les messages générés par l’applet de commande Write-Warning .

Par défaut, les messages d’avertissement s’affichent et l’exécution se poursuit, mais vous pouvez modifier ce comportement en modifiant la valeur de $WarningPreference.

La $WarningPreference variable prend l’une ActionPreference des valeurs d’énumération : SilentlyContinue, Stop, Continue, Inquire, Ignore, Suspend ou Break.

Les valeurs valides sont les suivantes :

  • Arrêter : affiche le message d’avertissement et un message d’erreur, puis arrête l’exécution.
  • Inquire : affiche le message d’avertissement, puis demande l’autorisation de continuer.
  • Continuer : (par défaut) Affiche le message d’avertissement, puis continue l’exécution.
  • SilentlyContinue : n’affiche pas le message d’avertissement. Continue l’exécution.

Vous pouvez utiliser le paramètre commun WarningAction d’une applet de commande pour déterminer comment PowerShell répond aux avertissements d’une commande particulière. Pour plus d’informations, consultez about_CommonParameters.

Exemples

Ces exemples montrent l’effet des différentes valeurs de $WarningPreference. Le paramètre WarningAction remplace la valeur de préférence.

Cet exemple montre l’effet de la valeur par défaut, Continuer.

$m = "This action can delete data."
Write-Warning -Message $m
WARNING: This action can delete data.

Cet exemple utilise le paramètre WarningAction avec la valeur SilentlyContinue pour supprimer l’avertissement. Le message ne s’affiche pas.

$m = "This action can delete data."
Write-Warning -Message $m -WarningAction SilentlyContinue

Cet exemple montre comment modifier la $WarningPreference variable en valeur SilentlyContinue . Le message ne s’affiche pas.

$WarningPreference = "SilentlyContinue"
$m = "This action can delete data."
Write-Warning -Message $m

Cet exemple utilise le paramètre WarningAction pour s’arrêter lorsqu’un avertissement est généré.

$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

Cet exemple montre comment modifier la $WarningPreference variable en valeur Inquire . L’utilisateur est invité à confirmer.

$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"):

Cet exemple utilise le paramètre WarningAction avec la valeur SilentlyContinue. La commande continue à s’exécuter et aucun message n’est affiché.

$m = "This action can delete data."
Write-Warning -Message $m -WarningAction SilentlyContinue

Cet exemple modifie la $WarningPreference valeur en 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

Cet exemple utilise WarningAction avec la valeur Inquire . L’utilisateur est invité lorsqu’un avertissement se produit.

$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

Détermine si WhatIf est automatiquement activé pour chaque commande qui la prend en charge. Lorsque WhatIf est activé, l’applet de commande signale l’effet attendu de la commande, mais n’exécute pas la commande.

Les valeurs valides sont les suivantes :

  • False (0, non activé) : (valeur par défaut) WhatIf n’est pas activé automatiquement. Pour l’activer manuellement, utilisez le paramètre WhatIf de l’applet de commande.
  • True (1, enabled) : WhatIf est automatiquement activé sur toute commande qui la prend en charge. Les utilisateurs peuvent utiliser le paramètre WhatIf avec la valeur False pour le désactiver manuellement, par -WhatIf:$falseexemple .

Exemples

Ces exemples montrent l’effet des différentes valeurs de $WhatIfPreference. Ils montrent comment utiliser le paramètre WhatIf pour remplacer la valeur de préférence pour une commande spécifique.

Cet exemple montre l’effet de la $WhatIfPreference variable définie sur la valeur par défaut, False. Utilisez Get-ChildItem pour vérifier que le fichier existe. Remove-Item supprime le fichier. Une fois le fichier supprimé, vous pouvez vérifier la suppression avec 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

Cet exemple montre l’effet de l’utilisation du paramètre WhatIf lorsque la valeur de $WhatIfPreference est False.

Vérifiez que le fichier existe.

Get-ChildItem -Path .\test2.txt
    Directory: C:\Test

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
-a---           2/28/2019    17:06             12 test2.txt

Utilisez le paramètre WhatIf pour déterminer le résultat de la tentative de suppression du fichier.

Remove-Item -Path .\test2.txt -WhatIf
What if: Performing the operation "Remove File" on target "C:\Test\test2.txt".

Vérifiez que le fichier n’a pas été supprimé.

Get-ChildItem -Path .\test2.txt
    Directory: C:\Test

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
-a---           2/28/2019    17:06             12 test2.txt

Cet exemple montre l’effet de la $WhatIfPreference variable définie sur la valeur True. Lorsque vous utilisez Remove-Item pour supprimer un fichier, le chemin d’accès du fichier s’affiche, mais le fichier n’est pas supprimé.

Essayez de supprimer un fichier. Un message s’affiche sur ce qui se passerait si Remove-Item était exécuté, mais le fichier n’est pas supprimé.

$WhatIfPreference = "True"
Remove-Item -Path .\test2.txt
What if: Performing the operation "Remove File" on target "C:\Test\test2.txt".

Utilisez Get-ChildItem pour vérifier que le fichier n’a pas été supprimé.

Get-ChildItem -Path .\test2.txt
    Directory: C:\Test

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
-a---           2/28/2019    17:06             12 test2.txt

Cet exemple montre comment supprimer un fichier lorsque la valeur de $WhatIfPreference est True. Il utilise le paramètre WhatIf avec la valeur .$false Utilisez Get-ChildItem pour vérifier que le fichier a été supprimé.

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

Voici des exemples d’applet Get-Process de commande qui ne prend pas en charge WhatIf et Stop-Process qui prend en charge WhatIf. La $WhatIfPreference valeur de la variable est True.

Get-Process ne prend pas en charge WhatIf. Lorsque la commande est exécutée, elle affiche le processus 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 prend en charge WhatIf. Le processus Winword n’est pas arrêté.

Stop-Process -Name Winword
What if: Performing the operation "Stop-Process" on target "WINWORD (15024)".

Vous pouvez remplacer le Stop-Process comportement WhatIf à l’aide du paramètre WhatIf avec la valeur .$false Le processus Winword est arrêté.

Stop-Process -Name Winword -WhatIf:$false

Pour vérifier que le processus Winword a été arrêté, utilisez 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

Voir aussi