Partager via

Utilisation des fonctionnalités expérimentales dans PowerShell

  • Article

La prise en charge des Fonctionnalités expérimentales dans PowerShell fournit un mécanisme permettant aux fonctionnalités expérimentales de coexister avec les fonctionnalités stables existantes dans PowerShell ou les modules PowerShell.

Une fonctionnalité expérimentale est une fonctionnalité dans laquelle la conception n’est pas finalisée. Les utilisateurs peuvent tester la fonctionnalité et fournir des commentaires. Lorsqu’une fonctionnalité expérimentale est finalisée, les modifications apportées à la conception deviennent des changements cassants.

Attention

Les fonctionnalités expérimentales ne sont pas destinées à être utilisées en production, car les changements peuvent être cassants. Les fonctionnalités expérimentales ne sont pas officiellement prises en charge. Toutefois, nous apprécions de recevoir des commentaires et des rapports de bogues. Vous pouvez consigner les problèmes dans le référentiel source GitHub.

Pour plus d’informations sur l’activation ou la désactivation de ces fonctionnalités, consultez about_Experimental_Features.

Cycle de vie de fonctionnalités expérimentales

La cmdlet Get-ExperimentalFeature renvoie toutes les fonctionnalités expérimentales disponibles dans PowerShell. Les fonctionnalités expérimentales peuvent provenir de modules ou du moteur PowerShell. Les fonctionnalités expérimentales basées sur les modules sont uniquement disponibles après votre importation du module. Dans l’exemple suivant, la PSDesiredStateConfiguration n’est pas chargée. La fonctionnalité PSDesiredStateConfiguration.InvokeDscResource n’est donc pas disponible.

Get-ExperimentalFeature

Name                             Enabled Source   Description
----                             ------- ------   -----------
PSCommandNotFoundSuggestion        False PSEngine Recommend potential commands based on fuzzy searc…
PSCommandWithArgs                  False PSEngine Enable `-CommandWithArgs` parameter for pwsh
PSFeedbackProvider                  True PSEngine Replace the hard-coded suggestion framework with …
PSLoadAssemblyFromNativeCode       False PSEngine Expose an API to allow assembly loading from nati…
PSModuleAutoLoadSkipOfflineFiles    True PSEngine Module discovery will skip over files that are ma…
PSSerializeJSONLongEnumAsNumber     True PSEngine Serialize enums based on long or ulong as an nume…
PSSubsystemPluginModel              True PSEngine A plugin model for registering and un-registering…

Utilisez les cmdlets Enable-ExperimentalFeature et Disable-ExperimentalFeature pour activer ou désactiver une fonctionnalité. Vous devez démarrer une nouvelle session PowerShell pour que cette modification soit appliquée. Exécutez la commande suivante pour activer la fonctionnalité PSCommandNotFoundSuggestion :

Enable-ExperimentalFeature PSCommandNotFoundSuggestion

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

Quand une fonctionnalité expérimentale devient mainstream, elle n’est pas disponible en tant que fonctionnalité expérimentale, car la fonctionnalité fait désormais partie du module ou du moteur PowerShell. Par exemple, la fonctionnalité PSAnsiRenderingFileInfo est devenue standard dans PowerShell 7.3. Vous obtenez la fonctionnalité du composant automatiquement.

Remarque

Certaines fonctionnalités ont des exigences de configuration, telles que des variables de préférence, qui doivent être définies pour obtenir les résultats souhaités à partir de la fonctionnalité.

Quand une fonctionnalité expérimentale est abandonnée, cette fonctionnalité n’est plus disponible dans PowerShell. Par exemple, la fonctionnalité PSNativePSPathResolution a été abandonnée dans PowerShell 7.3.

Fonctionnalités disponibles

Cet article décrit les fonctionnalités expérimentales disponibles et leur mode d’utilisation.

Légende

  • L’icône Expérimental indique que la fonctionnalité expérimentale est disponible dans la version de PowerShell
  • L’icône Standard indique la version de PowerShell où la fonctionnalité expérimentale est devenue standard
  • L’icône Plus disponible indique la version de PowerShell où la fonctionnalité expérimentale a été supprimée
Nom 7.2 7.4 7.5 (préversion)
PSCommandNotFoundSuggestion Expérimental Expérimental Standard
PSDesiredStateConfiguration.InvokeDscResource Expérimental Expérimental Expérimental
PSNativePSPathResolution Expérimental
PSSubsystemPluginModel Expérimental Expérimental Expérimental
PSNativeCommandArgumentPassing Expérimental
PSAnsiRenderingFileInfo Expérimental
PSLoadAssemblyFromNativeCode Expérimental Expérimental Expérimental
PSNativeCommandErrorActionPreference Standard
PSFeedbackProvider Expérimental Expérimental
PSModuleAutoLoadSkipOfflineFiles Expérimental Standard
PSCommandWithArgs Expérimental Standard
PSNativeWindowsTildeExpansion Expérimental
PSRedirectToVariable Expérimental
PSSerializeJSONLongEnumAsNumber Expérimental

PSAnsiRenderingFileInfo

Notes

Cette fonctionnalité est devenue standard dans PowerShell 7.3.

Des fonctionnalités de mise en force ANSI ont été ajoutées dans PowerShell 7.2. Cette fonctionnalité ajoute le membre $PSStyle.FileInfo et active la coloration des types de fichiers spécifiques.

  • $PSStyle.FileInfo.Directory : membre intégré pour spécifier la couleur des répertoires
  • $PSStyle.FileInfo.SymbolicLink : membre intégré pour spécifier la couleur des liens symboliques
  • $PSStyle.FileInfo.Executable : membre intégré pour spécifier la couleur des exécutables.
  • $PSStyle.FileInfo.Extension : utilisez ce membre pour définir les couleurs des différentes extensions de fichier. Le membre Extension préintègre des extensions pour les fichiers d’archive et PowerShell.

Pour plus d’informations, consultez about_Automatic_Variables.

PSCommandNotFoundSuggestion

Remarque

Cette fonctionnalité est devenue standard dans PowerShell 7.5-preview.5.

Recommande des commandes potentielles en fonction de la recherche de correspondance approximative après CommandNotFoundException.

PS> get

get: The term 'get' isn't recognized as the name of a cmdlet, function, script file,
or operable program. Check the spelling of the name, or if a path was included, verify
that the path is correct and try again.

Suggestion [4,General]: The most similar commands are: set, del, ft, gal, gbp, gc, gci,
gcm, gdr, gcs.

PSCommandWithArgs

Remarque

Cette fonctionnalité est devenue standard dans PowerShell 7.5-preview.5.

Cette fonctionnalité active le paramètre -CommandWithArgs pour pwsh. Ce paramètre vous permet d’exécuter une commande PowerShell avec des arguments. Contrairement à -Command, ce paramètre renseigne la variable intégrée $args qui peut être utilisée par la commande.

La première chaîne est la commande et les chaînes suivantes délimitées par des espaces sont les arguments.

Par exemple :

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

Cet exemple produit la sortie suivante :

arg: arg1
arg: arg2

Cette fonctionnalité a été ajoutée dans PowerShell 7.4-preview.2.

PSDesiredStateConfiguration.InvokeDscResource

Active la compilation en MOF sur les systèmes non-Windows et permet l’utilisation de Invoke-DSCResource sans LCM.

À partir de PowerShell 7.2, le module PSDesiredStateConfiguration est supprimé et cette fonctionnalité est désactivée par défaut. Pour l’activer, vous devez installer le module PSDesiredStateConfiguration v2.0.5 à partir de PowerShell Gallery et activer la fonctionnalité.

DSC v3 ne présente pas cette fonctionnalité expérimentale. DSC v3 prend uniquement en charge Invoke-DSCResource et n’utilise pas, ni ne prend en charge la compilation MOF. Pour plus d’informations, consultez PowerShell Desired State Configuration v3.

PSFeedbackProvider

Quand vous activez cette fonctionnalité, PowerShell utilise un nouveau fournisseur de feedback pour vous envoyer un feedback quand une commande est introuvable. Le fournisseur de feedback est extensible et peut être implémenté par des modules de tiers. Le fournisseur de feedback peut être utilisé par d’autres sous-systèmes, comme le sous-système de prédicteur, pour fournir des résultats IntelliSense prédictifs.

Cette fonctionnalité comprend deux fournisseurs de feedback intégrés :

  • GeneralCommandErrorFeedback utilise la même fonctionnalité de suggestion que celle qui existe aujourd’hui

  • UnixCommandNotFound, disponible sur Linux, fournit un feedback similaire à bash.

    UnixCommandNotFound sert à la fois de fournisseur de feedback et de prédicteur. La suggestion de la commande « command-not-found » est utilisée à la fois pour fournir le feedback quand la commande est introuvable dans une exécution interactive et pour fournir des résultats IntelliSense prédictifs pour la ligne de commande suivante.

Cette fonctionnalité a été ajoutée dans PowerShell 7.4-preview.3.

PSLoadAssemblyFromNativeCode

Expose une API pour permettre le chargement d’assembly à partir du code natif.

PSModuleAutoLoadSkipOfflineFiles

Remarque

Cette fonctionnalité est devenue standard dans PowerShell 7.5-preview.5.

Avec cette fonctionnalité activée, si le PSModulePath d’un utilisateur contient un dossier provenant d’un fournisseur cloud, comme OneDrive, PowerShell ne déclenche plus le téléchargement de tous les fichiers contenus dans ce dossier. Tous les fichiers marqués comme non téléchargés sont ignorés. Les utilisateurs qui utilisent des fournisseurs cloud pour synchroniser leurs modules entre des machines doivent marquer le dossier du module comme Épinglé ou l’état équivalent pour les fournisseurs autres que OneDrive. Le fait de marquer le dossier de module comme Épinglé garantit que les fichiers sont toujours conservés sur le disque.

Cette fonctionnalité a été ajoutée dans PowerShell 7.4-preview.1.

PSNativeCommandArgumentPassing

Notes

Cette fonctionnalité est devenue standard dans PowerShell 7.3.

Quand cette fonctionnalité expérimentale est activée, PowerShell utilise la propriété ArgumentList de l’objet StartProcessInfo plutôt que notre mécanisme actuel de reconstruction d’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. Historiquement, les guillemets doivent être placés dans une séquence d’échappement. Il n’est pas possible de fournir des arguments vides à une application native. Utilisez le jeton d’arrêt d’analyse (--%) ou l’applet de commande Start-Process pour contourner le passage d’argument natif si nécessaire.

Cette fonctionnalité ajoute une nouvelle variable de préférence $PSNativeCommandArgumentPassing qui contrôle ce comportement. Cette variable vous permet de sélectionner le comportement au moment de l’exécution. Les valeurs valides sont Legacy, Standard et Windows. 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.

Legacy est le comportement historique. Le comportement des modes Windows et Standard est le même, sauf qu’en mode Windows, les appels des fichiers suivants utilisent automatiquement le passage de l’argument de style Legacy.

  • cmd.exe
  • find.exe
  • cscript.exe
  • wscript.exe
  • sqlcmd.exe - Ajout dans PowerShell 7.3.1
  • se terminant par .bat
  • se terminant par .cmd
  • se terminant par .js
  • se terminant par .vbs
  • se terminant par .wsf

Si $PSNativeCommandArgumentPassing est défini sur Legacy ou Standard, l’analyseur ne recherche pas ces fichiers.

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.

Notes

Les exemples suivants utilisent l’outil TestExe.exe. Vous pouvez générer TestExe à partir du code source. Consultez TestExe dans le référentiel source PowerShell.

Nouveaux comportements mis à disposition par ce changement :

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

    PS> $a = 'a" "b'
PS> TestExe -echoargs $a 'c" "d' e" "f
Arg 0 is <a" "b>
Arg 1 is <c" "d>
Arg 2 is <e f>

  • Les chaînes vides en tant qu’arguments sont conservées :

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

Pour obtenir d’autres exemples du nouveau comportement, consultez about_Parsing.

PowerShell 7.3 a également ajouté la possibilité de tracer la liaison de paramètres pour les commandes natives. Pour plus d’informations, consultez Trace-Command.

PSNativeCommandErrorActionPreference

Remarque

Cette fonctionnalité est devenue standard dans PowerShell 7.4.

En général, les commandes natives retournent un code de sortie à l’application appelante : zéro en cas de réussite, autre que zéro en cas d’échec. Toutefois, les commandes natives ne participent pas actuellement au flux d’erreurs PowerShell. La sortie stderr redirigée n’est pas interprétée de la même façon que le flux d’erreurs PowerShell. De nombreuses commandes natives utilisent stderr comme flux d’informations ou de commentaires, donc seul le code de sortie est important. Les utilisateurs qui travaillent avec des commandes natives dans leurs scripts doivent vérifier l’état de sortie après chaque appel en utilisant quelque chose de similaire à l’exemple suivant :

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

Toutefois, cet exemple ne prend pas en charge tous les cas où $? peut avoir la valeur false à partir d’une applet de commande ou d’une erreur de fonction, rendant $LASTEXITCODE obsolète.

Cette fonctionnalité implémente la variable de préférence $PSNativeCommandUseErrorActionPreference qui contrôle la façon dont les erreurs de commandes natives sont gérées dans PowerShell. Cela permet aux erreurs de commandes natives de produire des objets d’erreur qui sont ajoutés au flux d’erreurs PowerShell et peut mettre fin à l’exécution du script sans traitement supplémentaire.

$PSNativeCommandUseErrorActionPreference a la valeur $false par défaut. Avec la préférence définie sur $true vous obtenez le comportement suivant :

  • Quand $ErrorActionPreference = 'Stop', les scripts s’interrompent lorsqu’une commande native retourne un code de sortie autre que zéro.
  • Quand $ErrorActionPreference = 'Continue' (valeur par défaut), les messages d’erreur PowerShell s’affichent pour les erreurs de commandes natives, mais les scripts ne s’interrompent pas.

PSNativePSPathResolution

Notes

Cette fonctionnalité expérimentale a été supprimée dans PowerShell 7.3 et n’est plus prise en charge.

Si un chemin PSDrive qui utilise le fournisseur FileSystem est passé à une commande native, le chemin du fichier résolu est passé à la commande native. Cela signifie qu’une commande comme code temp:/test.txt fonctionne à présent comme prévu.

En outre, si le chemin commence par ~ sur Windows, il est résolu en chemin d’accès complet et transmis à la commande native. Dans les deux cas, le chemin est normalisé aux séparateurs de répertoire pour le système d’exploitation approprié.

  • Si le chemin n’est pas PSDrive ni ~ (sur Windows), la normalisation de chemin d’accès n’est pas effectuée
  • Si le chemin est placé entre guillemets simples, il n’est pas résolu et traité comme littéral

PSRedirectToVariable

Remarque

Cette fonctionnalité expérimentale a été ajoutée dans PowerShell 7.5-preview.4.

Lorsqu’elle est activée, cette fonctionnalité prend en charge la redirection vers le lecteur de variable. Cette fonctionnalité vous permet de rediriger les données vers une variable en utilisant la syntaxe variable:name. PowerShell inspecte la cible de la redirection et s’il utilise le fournisseur de variables, il appelle Set-Variable plutôt que Out-File.

L’exemple suivant montre comment rediriger la sortie d’une commande vers une variable :

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

Output 1
Output 2
WARNING: Warning, Warning!

PSSubsystemPluginModel

Cette fonctionnalité active le modèle de plug-in de sous-système dans PowerShell. La fonctionnalité permet de diviser les composants de System.Management.Automation.dll en sous-systèmes individuels qui résident dans leur propre assembly. Cette division réduit l’encombrement de disque du moteur PowerShell principal et permet à ces composants de devenir des fonctionnalités facultatives pour une installation PowerShell minimale.

Actuellement, seul le sous-système CommandPredictor est pris en charge. Ce sous-système est utilisé avec le module PSReadLine pour fournir des plug-ins de prédiction personnalisés. À l’avenir, Job, CommandCompleter, Remoting et d’autres composants pourraient être divisés en assemblys de sous-système en dehors de System.Management.Automation.dll.

La fonctionnalité expérimentale comprend une nouvelle applet de commande, Get-PSSubsystem. Cette applet de commande est disponible uniquement lorsque la fonctionnalité est activée. Cette applet de commande retourne des informations sur les sous-systèmes disponibles sur le système.

PSNativeWindowsTildeExpansion

Lorsque cette fonctionnalité est activée, PowerShell développe un signe tilde sans guillemets (~) dans le dossier d’accueil actuel de l’utilisateur avant d’invoquer des commandes natives. Les exemples suivants montrent le fonctionnement de la fonctionnalité.

Avec la fonctionnalité désactivée, le signe tilde est passé à la commande native en tant que chaîne littérale.

PS> cmd.exe /c echo ~
~

Avec la fonctionnalité activée, PowerShell développe le signe tilde avant son passage à la commande native.

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

Cette fonctionnalité s’applique uniquement à Windows. Sur les plateformes non Windows, l’expansion du signe tilde est traité nativement.

Cette fonctionnalité a été ajoutée dans PowerShell 7.5-preview.2.

PSSerializeJSONLongEnumAsNumber

Cette fonctionnalité permet à l’applet de commande ConvertTo-Json de sérialiser toutes les valeurs enum en fonction de Int64/long ou UInt64/ulong sous forme de valeur numérique plutôt que de représenter cette valeur enum sous forme de chaîne. Cela aligne le comportement de sérialisation d’enum avec d’autres types de base enum où l’applet de commande sérialise les enums comme valeur numérique. Utilisez le paramètre EnumsAsStrings pour sérialiser en tant que représentation sous forme de chaîne.

Par exemple :

# PSSerializeJSONLongEnumAsNumber disabled
@{
    Key = [System.Management.Automation.Tracing.PowerShellTraceKeywords]::Cmdlets
} | ConvertTo-Json
# { "Key": "Cmdlets" }

# PSSerializeJSONLongEnumAsNumber enabled
@{
    Key = [System.Management.Automation.Tracing.PowerShellTraceKeywords]::Cmdlets
} | ConvertTo-Json
# { "Key": 32 }

# -EnumsAsStrings to revert back to the old behaviour
@{
    Key = [System.Management.Automation.Tracing.PowerShellTraceKeywords]::Cmdlets
} | ConvertTo-Json -EnumsAsStrings
# { "Key": "Cmdlets" }