Utilisation des fonctionnalités expérimentales dans PowerShell
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…
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
indique que la fonctionnalité expérimentale est disponible dans la version de PowerShell - L’icône
indique la version de PowerShell où la fonctionnalité expérimentale est devenue standard - L’icône
indique la version de PowerShell où la fonctionnalité expérimentale a été supprimée
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
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
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
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.exefind.execscript.exewscript.exesqlcmd.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
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.
Commentaires
Bientôt disponible : Tout au long de 2024, nous allons supprimer progressivement GitHub Issues comme mécanisme de commentaires pour le contenu et le remplacer par un nouveau système de commentaires. Pour plus d’informations, consultez https://aka.ms/ContentUserFeedback.
Envoyer et afficher des commentaires pour