Share via

about_Command_Precedence

  • Article

Description courte

Décrit comment PowerShell détermine la commande à exécuter.

Description longue

La priorité des commandes décrit comment PowerShell détermine la commande à exécuter lorsqu’une session contient plusieurs commandes portant le même nom. Les commandes d’une session peuvent être masquées ou remplacées par des commandes portant le même nom. Cet article vous montre comment exécuter des commandes masquées et comment éviter les conflits nom-commande.

Priorité des commandes

Lorsqu’une session PowerShell inclut plusieurs commandes portant le même nom, PowerShell détermine la commande à exécuter à l’aide des règles suivantes.

Si vous spécifiez le chemin d’accès à une commande, PowerShell exécute la commande à l’emplacement spécifié par le chemin d’accès.

Par exemple, la commande suivante exécute le script FindDocs.ps1 dans le répertoire « C :\TechDocs » :

C:\TechDocs\FindDocs.ps1

En tant que fonctionnalité de sécurité, PowerShell n’exécute pas de commandes exécutables (natives), y compris les scripts PowerShell, sauf si la commande se trouve dans un chemin d’accès répertorié dans la variable $env:path d’environnement Path ou si vous spécifiez le chemin d’accès au fichier de script.

Pour exécuter un script qui se trouve dans le répertoire actif, spécifiez le chemin d’accès complet ou tapez un point .\ pour représenter le répertoire actif.

Par exemple, pour exécuter le fichier FindDocs.ps1 dans le répertoire actif, tapez :

.\FindDocs.ps1

Utilisation de caractères génériques dans l’exécution

Vous pouvez utiliser des caractères génériques dans l’exécution de la commande. L’utilisation de caractères génériques est également appelée globbing.

PowerShell exécute un fichier qui a une correspondance de caractères génériques, avant une correspondance littérale.

Par exemple, considérez un répertoire avec les fichiers suivants :

Get-ChildItem C:\temp\test


    Directory: C:\temp\test


Mode                LastWriteTime         Length Name
----                -------------         ------ ----
-a----        5/20/2019   2:29 PM             28 a.ps1
-a----        5/20/2019   2:29 PM             28 [a1].ps1

Les deux fichiers de script ont le même contenu : $MyInvocation.MyCommand.Path. Cette commande affiche le nom du script appelé.

Lorsque vous exécutez [a1].ps1, le fichier a.ps1 est exécuté même s’il [a1].ps1 s’agit d’une correspondance littérale.

C:\temp\test\[a1].ps1

C:\temp\test\a.ps1

À présent, nous allons supprimer le a.ps1 fichier et essayer de l’exécuter à nouveau.

Remove-Item C:\temp\test\a.ps1
C:\temp\test\[a1].ps1

C:\temp\test\[a1].ps1

Vous pouvez voir la sortie qui s’exécute [a1].ps1 cette fois, car la correspondance littérale est la seule correspondance de fichier pour ce modèle de caractères génériques.

Pour plus d’informations sur la façon dont PowerShell utilise les caractères génériques, consultez about_Wildcards.

Notes

Pour limiter la recherche à un chemin relatif, vous devez préfixer le nom du script avec le chemin d’accès .\ . Cela limite la recherche de commandes aux fichiers de ce chemin relatif. Sans ce préfixe, d’autres syntaxes PowerShell peuvent entrer en conflit et il existe peu de garanties que le fichier sera trouvé.

Si vous ne spécifiez pas de chemin d’accès, PowerShell utilise l’ordre de priorité suivant lorsqu’il exécute des commandes pour tous les éléments chargés dans la session active :

  1. Alias
  2. Fonction
  3. Applet de commande
  4. Fichiers exécutables externes (programmes et scripts non PowerShell)

Par conséquent, si vous tapez « help », PowerShell recherche d’abord un alias nommé help, puis une fonction nommée Help, et enfin une applet de commande nommée Help. Il exécute le premier help élément qu’il trouve.

Par exemple, si votre session contient une applet de commande et une fonction, toutes deux nommées Get-Map, lorsque vous tapez Get-Map, PowerShell exécute la fonction .

Notes

Cela s’applique uniquement aux commandes chargées. S’il existe un build exécutable et un alias build pour une fonction portant le nom de à l’intérieur d’un Invoke-Build module qui n’est pas chargé dans la session active, PowerShell exécute l’exécutable à la build place. Il ne charge pas automatiquement les modules s’il trouve l’exécutable externe dans ce cas. Ce n’est que lorsqu’aucun exécutable externe n’est trouvé qu’un alias, une fonction ou une applet de commande portant le nom donné est appelé, déclenchant ainsi le chargement automatique de son module.

Lorsque la session contient des éléments du même type qui portent le même nom, PowerShell exécute l’élément le plus récent.

Par exemple, si vous importez une autre Get-Date applet de commande à partir d’un module, lorsque vous tapez Get-Date, PowerShell exécute la version importée sur la version native.

Éléments masqués et remplacés

Grâce à ces règles, les éléments peuvent être remplacés ou masqués par des éléments portant le même nom.

Les éléments sont « masqués » ou « masqués » si vous pouvez toujours accéder à l’élément d’origine, par exemple en qualifiant le nom de l’élément avec un nom de module ou de composant logiciel enfichable.

Par exemple, si vous importez une fonction portant le même nom qu’une applet de commande dans la session, l’applet de commande est masquée (mais pas remplacée), car elle a été importée à partir d’un composant logiciel enfichable ou d’un module.

Les éléments sont « remplacés » ou « remplacés » si vous ne pouvez plus accéder à l’élément d’origine.

Par exemple, si vous importez une variable portant le même nom qu’une variable dans la session, la variable d’origine est remplacée et n’est plus accessible. Vous ne pouvez pas qualifier une variable avec un nom de module.

En outre, si vous tapez une fonction sur la ligne de commande, puis importez une fonction portant le même nom, la fonction d’origine est remplacée et n’est plus accessible.

Recherche de commandes masquées

Le paramètre All de l’applet de commande Get-Command obtient toutes les commandes portant le nom spécifié, même si elles sont masquées ou remplacées. À partir de PowerShell 3.0, par défaut, Get-Command obtient uniquement les commandes qui s’exécutent lorsque vous tapez le nom de la commande.

Dans les exemples suivants, la session inclut une Get-Date fonction et une applet de commande Get-Date .

La commande suivante obtient la Get-Date commande qui s’exécute lorsque vous tapez Get-Date.

Get-Command Get-Date

CommandType     Name                      ModuleName
-----------     ----                      ----------
Function        Get-Date

La commande suivante utilise le paramètre All pour obtenir toutes les Get-Date commandes.

Get-Command Get-Date -All

CommandType     Name                      ModuleName
-----------     ----                      ----------
Function        Get-Date
Cmdlet          Get-Date                  Microsoft.PowerShell.Utility

Exécution de commandes masquées

Vous pouvez exécuter des commandes particulières en spécifiant des propriétés d’élément qui distinguent la commande des autres commandes qui peuvent avoir le même nom. Vous pouvez utiliser cette méthode pour exécuter n’importe quelle commande, mais elle est particulièrement utile pour exécuter des commandes masquées.

Utilisation de noms qualifiés

L’utilisation du nom qualifié de module d’une applet de commande vous permet d’exécuter des commandes masquées par un élément portant le même nom. Par exemple, vous pouvez exécuter l’applet de Get-Date commande en la qualifiant avec son nom de module Microsoft.PowerShell.Utility.

Utilisez cette méthode préférée lors de l’écriture de scripts que vous envisagez de distribuer. Vous ne pouvez pas prédire quelles commandes peuvent être présentes dans la session dans laquelle le script s’exécute.

New-Alias -Name "Get-Date" -Value "Get-ChildItem"
Microsoft.PowerShell.Utility\Get-Date

Tuesday, September 4, 2018 8:17:25 AM

Pour exécuter une New-Map commande qui a été ajoutée par le MapFunctions module, utilisez son nom qualifié de module :

MapFunctions\New-Map

Pour rechercher le module à partir duquel une commande a été importée, utilisez la propriété ModuleName des commandes.

(Get-Command <command-name>).ModuleName

Par exemple, pour trouver la source de l’applet Get-Date de commande, tapez :

(Get-Command Get-Date).ModuleName

Microsoft.PowerShell.Utility

Notes

Vous ne pouvez pas qualifier des variables ou des alias.

Utilisation de l’opérateur d’appel

Vous pouvez également utiliser l’opérateur Call& pour exécuter des commandes masquées en le combinant avec un appel à Get-ChildItem (l’alias est « dir ») Get-Command ou Get-Module.

L’opérateur d’appel exécute des chaînes et des blocs de script dans une étendue enfant. Pour plus d’informations, consultez about_Operators.

Par exemple, si vous avez une fonction nommée Map masquée par un alias nommé Map, utilisez la commande suivante pour exécuter la fonction.

&(Get-Command -Name Map -CommandType Function)

ou

&(dir Function:\map)

Vous pouvez également enregistrer votre commande masquée dans une variable pour faciliter son exécution.

Par exemple, la commande suivante enregistre la Map fonction dans la $myMap variable, puis utilise l’opérateur pour l’exécuter Call .

$myMap = (Get-Command -Name map -CommandType function)
&($myMap)

Éléments remplacés

Un élément « remplacé » est un élément auquel vous ne pouvez plus accéder. Vous pouvez remplacer des éléments en important des éléments du même nom à partir d’un module ou d’un composant logiciel enfichable.

Par exemple, si vous tapez une Get-Map fonction dans votre session et que vous importez une fonction appelée Get-Map, elle remplace la fonction d’origine. Vous ne pouvez pas le récupérer dans la session active.

Les variables et les alias ne peuvent pas être masqués, car vous ne pouvez pas utiliser un opérateur d’appel ou un nom qualifié pour les exécuter. Lorsque vous importez des variables et des alias à partir d’un module ou d’un composant logiciel enfichable, ils remplacent les variables de la session par le même nom.

Éviter les conflits de noms

La meilleure façon de gérer les conflits de noms de commandes consiste à les empêcher. Lorsque vous nommez vos commandes, utilisez un nom unique. Par exemple, ajoutez vos initiales ou votre acronyme de nom de société aux noms de vos commandes.

En outre, lorsque vous importez des commandes dans votre session à partir d’un module PowerShell ou d’une autre session, utilisez le Prefix paramètre Import-Module ou

Applet de commande Import-PSSession pour ajouter un préfixe aux noms des commandes.

Par exemple, la commande suivante évite tout conflit avec les Get-Date applets de commande et Set-Date fournies avec PowerShell lorsque vous importez le DateFunctions module.

Import-Module -Name DateFunctions -Prefix ZZ

Exécution d’exécutables externes

PowerShell traite les extensions de fichier répertoriées dans la variable d’environnement $env:PATHEXT comme des fichiers exécutables. Les fichiers exécutables Windows sont des fichiers avec .COMdes extensions de fichier , .CPLou .EXE . Les exécutables Windows et tous les autres fichiers avec des extensions répertoriées dans $env:PATHEXT sont exécutés dans la session de console active.

Les fichiers qui ne sont pas des exécutables Windows sont remis à Windows à traiter. Windows recherche l’association de fichiers et exécute le verbe Windows Shell par défaut pour l’extension. Pour que Windows puisse prendre en charge l’exécution par extension de fichier, l’association doit être inscrite auprès du système.

Vous pouvez inscrire le moteur exécutable pour une extension de fichier à l’aide ftype des commandes et assoc de l’interpréteur de commandes CMD. PowerShell n’a pas de méthode directe pour inscrire le gestionnaire de fichiers. Pour plus d’informations, consultez la documentation relative à la commande ftype .

Pour que PowerShell voit une extension de fichier comme exécutable dans la session active, vous devez ajouter l’extension à la variable d’environnement $env:PATHEXT .

Voir aussi