Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Brève description
Décrit comment PowerShell analyse les commandes.
Description longue
Lorsque vous entrez une commande à l’invite de commandes, PowerShell divise le texte de la commande en une série de segments appelés jetons, puis détermine comment interpréter chaque jeton.
Par exemple, si vous tapez :
Write-Host book
PowerShell interrompt la commande en deux jetons, Write-Host et book, et interprète chaque jeton indépendamment à l’aide de l’un des deux principaux modes d’analyse : le mode expression et le mode argument.
Remarque
Lorsque PowerShell analyse l’entrée de commande, elle tente de résoudre les noms de commandes en applets de commande ou exécutables natifs. Si le nom d’une commande n’a pas de correspondance exacte, PowerShell ajoute Get- à la commande un verbe par défaut. Par exemple, PowerShell analyse Process en tant que Get-Process. Il n’est pas recommandé d’utiliser cette fonctionnalité pour les raisons suivantes :
- C’est inefficace. Cela fait effectuer plusieurs recherches par PowerShell.
- Les programmes externes portant le même nom sont résolus en premier, vous ne pouvez donc pas exécuter l’applet de commande prévue.
-
Get-HelpetGet-Commandne reconnaissent pas les noms sans verbe.
Mode d'expression
Le mode expression est destiné à combiner des expressions, requises pour la manipulation de valeurs dans un langage de script. Les expressions sont des représentations de valeurs dans la syntaxe PowerShell et peuvent être simples ou composites, par exemple :
Les expressions littérales sont des représentations directes de leurs valeurs :
'hello'
32
Les expressions de variable portent la valeur de la variable qu’elles référencent :
$x
$script:path
Les opérateurs combinent d’autres expressions pour l’évaluation :
-12
-not $Quiet
3 + 7
$input.Length -gt 1
- Les littéraux de chaînes de caractères doivent être placés entre guillemets.
- Les nombres sont traités comme des valeurs numériques et non comme une série de caractères (sauf s'ils sont échappés).
-
Opérateurs, y compris les opérateurs unaires tels que
-et-notet les opérateurs binaires tels que+et-gt, sont interprétés comme des opérateurs et appliquent leurs opérations respectives sur leurs arguments (opérandes). -
Les expressions d’attribut et de conversion sont analysées comme des expressions et appliquées à des expressions subordonnées, par exemple
[int] '7'. - Les références de variables sont évaluées à leurs valeurs, mais le splatting (c’est-à-dire le collage d’ensembles de paramètres préremplis) est interdit et provoque une erreur d’analyseur.
- Tout le reste sera traité comme une commande à invoquer.
Mode d'argumentation
Lors de l’analyse, PowerShell cherche d’abord à interpréter l’entrée en tant qu’expression. Toutefois, lorsqu’un appel de commande est rencontré, l’analyse continue en mode argument. Si vous avez des arguments qui contiennent des espaces, tels que des chemins d’accès, vous devez placer ces valeurs d’argument entre guillemets.
Le mode Argument est conçu pour l’analyse des arguments et des paramètres pour les commandes dans un environnement shell. Toutes les entrées sont traitées comme une chaîne extensible, sauf si elle utilise l’une des syntaxes suivantes :
Le signe dollar (
$) suivi d’un nom de variable commence une référence de variable, sinon elle est interprétée comme faisant partie de la chaîne extensible. La référence à une variable peut inclure l'accès à un membre ou l'indexation.- Des caractères supplémentaires suivants des références de variables simples, telles que
$HOME, sont considérés comme faisant partie du même argument. Placez le nom de la variable dans les accolades ({}) pour le séparer des caractères suivants. Par exemple :${HOME}. - Lorsque la référence de variable inclut l’accès aux membres, le premier des caractères supplémentaires est considéré comme le début d’un nouvel argument. Par exemple,
$HOME.Length-moregénère deux arguments : la valeur de$HOME.Lengthet la chaîne littérale-more.
- Des caractères supplémentaires suivants des références de variables simples, telles que
Les guillemets (
'et") commencent les chaînes de caractères.Les accolades (
{}) commencent un nouveau bloc de scriptLes virgules (
,) introduisent des listes passées sous forme de tableaux, sauf lorsque la commande à appeler est une application native, auquel cas elles sont interprétées comme faisant partie de la chaîne extensible. Les virgules initiales, consécutives ou de fin ne sont pas prises en charge.Parenthèses (
()) commencent une nouvelle expressionL’opérateur de sous-expression (
$()) commence une expression incorporéeLe signe at initial (
@) commence les syntaxes d'expression telles que le splatting (@args), les tableaux (@(1,2,3)) et les littéraux de table de hachage (@{a=1;b=2}).(),$()et@()au début d’un jeton créent un contexte d’analyse qui peut contenir des expressions ou des commandes imbriquées.- Lorsqu’il est suivi de caractères supplémentaires, le premier caractère supplémentaire est considéré comme le début d’un nouvel argument distinct.
- Lorsqu’il est précédé d’un littéral
$()sans guillemets, il fonctionne comme une chaîne extensible,()commence un nouvel argument qui est une expression et@()est considéré comme littéral@au()début d’un nouvel argument qui est une expression.
Tout le reste est traité comme une chaîne extensible, à l'exception des métacaractères qui doivent encore être échappés.
- Les métacharacters en mode argument (caractères ayant une signification syntactique spéciale) sont :
<space> ' " ` , ; ( ) { } | & < > @ #. Parmi ceux-ci,< > @ #ne sont spéciaux qu'au début d'un symbole.
- Les métacharacters en mode argument (caractères ayant une signification syntactique spéciale) sont :
Le jeton d'arrêt d'analyse (
--%) modifie l'interprétation de tous les arguments restants. Pour plus d'informations, reportez-vous à la section stop-parsing token des jetons ci-dessous.
Exemples
Le tableau suivant fournit plusieurs exemples de jetons traités en mode expression et en mode argument et l’évaluation de ces jetons. Pour ces exemples, la valeur de la variable $a est 4.
| Exemple : | mode de fonctionnement | Résultat |
|---|---|---|
2 |
L'Expression | 2 (entier) |
`2 |
L'Expression | "2" (commande) |
Write-Output 2 |
L'Expression | 2 (entier) |
2+2 |
L'Expression | 4 (entier) |
Write-Output 2+2 |
Raisonnement | "2+2" (chaîne) |
Write-Output(2+2) |
L'Expression | 4 (entier) |
$a |
L'Expression | 4 (entier) |
Write-Output $a |
L'Expression | 4 (entier) |
$a+2 |
L'Expression | 6 (entier) |
Write-Output $a+2 |
Raisonnement | "4+2" (chaîne de caractères) |
$- |
Raisonnement | "$-" (commande) |
Write-Output $- |
Raisonnement | "$-" (chaîne) |
a$a |
L'Expression | "a$a" (commande) |
Write-Output a$a |
Raisonnement | "a4" (chaîne) |
a'$a' |
L'Expression | "a$a" (commande) |
Write-Output a'$a' |
Raisonnement | "a$a" (chaîne de caractères) |
a"$a" |
L'Expression | "a$a" (commande) |
Write-Output a"$a" |
Raisonnement | "a4" (chaîne) |
a$(2) |
L'Expression | "a$(2)" (commande) |
Write-Output a$(2) |
Raisonnement | "a2" (chaîne) |
Chaque jeton peut être interprété comme un type d’objet, tel que booléen ou string. PowerShell tente de déterminer le type d’objet de l’expression. Le type d’objet dépend du type de paramètre attendu par une commande et de savoir si PowerShell sait comment convertir l’argument en type correct. Le tableau suivant présente plusieurs exemples de types attribués aux valeurs retournées par les expressions.
| Exemple : | mode de fonctionnement | Résultat |
|---|---|---|
Write-Output !1 |
argument | "!1" (chaîne de caractères) |
Write-Output (!1) |
expression | Faux (booléen) |
Write-Output (2) |
expression | 2 (entier) |
Set-Variable AB A,B |
argument | 'A', 'B' (tableau) |
CMD /CECHO A,B |
argument | 'A,B' (chaîne) |
CMD /CECHO $AB |
expression | 'A B' (tableau) |
CMD /CECHO :$AB |
argument | ':A B' (chaîne) |
Passage d’arguments à des commandes natives
Lors de l’exécution de commandes natives à partir de PowerShell, les arguments sont d’abord analysés par PowerShell. Les arguments analysés sont ensuite joints à une seule chaîne avec chaque paramètre séparé par un espace.
Par exemple, la commande suivante appelle le programme icacls.exe.
icacls X:\VMS /grant Dom\HVAdmin:(CI)(OI)F
Pour exécuter cette commande dans PowerShell 2.0, vous devez utiliser des caractères d’échappement pour empêcher PowerShell de mal interpréter les parenthèses.
icacls X:\VMS /grant Dom\HVAdmin:`(CI`)`(OI`)F
Le jeton d'arrêt d'analyse
À partir de PowerShell 3.0, vous pouvez utiliser le jeton d'arrêt d'analyse (--%) pour empêcher PowerShell d'interpréter l'entrée en tant que commandes ou expressions PowerShell.
Remarque
Le jeton d’analyse d’arrêt est uniquement destiné à être utilisé sur les plates-formes Windows.
Lorsque vous appelez une commande native, placez la balise stop-parsing avant les arguments du programme. Cette technique est beaucoup plus facile que d’utiliser des caractères d’échappement pour éviter une mauvaise interprétation.
Lorsqu'il rencontre une balise stop-parsing, PowerShell traite les caractères restants de la ligne comme un littéral. La seule interprétation qu’elle effectue consiste à remplacer les valeurs des variables d’environnement qui utilisent la notation Windows standard, telle que %USERPROFILE%.
icacls X:\VMS --% /grant Dom\HVAdmin:(CI)(OI)F
PowerShell envoie la chaîne de commande suivante au programme icacls.exe :
X:\VMS /grant Dom\HVAdmin:(CI)(OI)F
Le jeton d'arrêt de l'analyse n'est effectif que jusqu'au prochain caractère de nouvelle ligne ou de pipeline. Vous ne pouvez pas utiliser un caractère de continuation (`) pour étendre son effet ou utiliser un délimiteur de commande (;) pour mettre fin à son effet.
À l’exception des %variable% références de variables d’environnement, vous ne pouvez pas incorporer d’autres éléments dynamiques dans la commande. L’échappement d’un % caractère en tant que %%, comme vous pouvez le faire dans les fichiers de commandes, n’est pas pris en charge. Les jetons %<name>% sont invariablement développés. Si <name> ne fait pas référence à une variable d’environnement définie, le jeton est transmis par as-is.
Vous ne pouvez pas utiliser la redirection de flux (comme >file.txt) car elles sont passées mot pour mot en tant qu’arguments à la commande cible.
Transmission d'arguments contenant des caractères de citation
Certaines commandes natives attendent des arguments qui contiennent des guillemets. Normalement, l’analyse de ligne de commande de PowerShell supprime le caractère de guillemet que vous avez fourni. Les arguments analysés sont ensuite joints à une seule chaîne avec chaque paramètre séparé par un espace. Cette chaîne est ensuite affectée à la propriété Arguments d’un ProcessStartInfo objet. Les guillemets dans la chaîne doivent être placés dans une séquence d’échappement en utilisant des guillemets supplémentaires ou des barres obliques inverses (\).
Remarque
La barre oblique inverse (\) n’est pas reconnue comme un caractère d’échappement par PowerShell. Il s’agit du caractère d’échappement utilisé par l’API sous-jacente pour ProcessStartInfo.Arguments.
Pour plus d’informations sur les exigences d’échappement, consultez la documentation de ProcessStartInfo.Arguments.
Les exemples suivants utilisant l’outil TestExe.exe . Cet outil est utilisé par les tests Pester dans le dépôt source PowerShell. L’objectif de ces exemples est de passer le chemin d’accès "C:\Program Files (x86)\Microsoft\" du répertoire à une commande native afin qu’il ait reçu le chemin sous forme de chaîne entre guillemets.
Le paramètre echoargs d’affiche TestExe les valeurs reçues en tant qu’arguments pour l’exécutable. Vous pouvez utiliser cet outil pour vérifier que vous avez correctement échappé les caractères dans vos arguments.
TestExe -echoargs """""${env:ProgramFiles(x86)}\Microsoft\\"""""
TestExe -echoargs """""C:\Program Files (x86)\Microsoft\\"""""
TestExe -echoargs "\""C:\Program Files (x86)\Microsoft\\"""
TestExe -echoargs --% "\"C:\Program Files (x86)\Microsoft\\"
TestExe -echoargs --% """C:\Program Files (x86)\Microsoft\\""
TestExe -echoargs --% """%ProgramFiles(x86)%\Microsoft\\""
La sortie est la même pour tous les exemples :
Arg 0 is <"C:\Program Files (x86)\Microsoft\">
Vous pouvez générer TestExe à partir du code source. Voir TestExe.
Passage d’arguments à des commandes PowerShell
À compter de PowerShell 3.0, vous pouvez utiliser le jeton de fin de paramètres (--) pour empêcher PowerShell d’interpréter l’entrée en tant que paramètres PowerShell. Il s’agit d’une convention spécifiée dans la spécification POSIX Shell et Utilities.
Le jeton de fin de paramètres (--) indique que tous les arguments suivants doivent être passés sous leur forme réelle, comme si les guillemets doubles étaient placés autour d’eux. Par exemple, en utilisant -- vous pouvez générer la chaîne -InputObject sans utiliser de guillemets ni l’interpréter comme un paramètre :
Write-Output -- -InputObject
-InputObject
Contrairement au jeton d’analyse stop (--%), toutes les valeurs qui suivent le jeton de -- peuvent être interprétées comme des expressions par PowerShell.
Write-Output -- -InputObject $env:PROCESSOR_ARCHITECTURE
-InputObject
AMD64
Ce comportement s’applique uniquement aux commandes PowerShell. Si vous utilisez le jeton -- lors de l’appel d’une commande externe, la chaîne -- est passée en tant qu’argument à cette commande.
TestExe -echoargs -a -b -- -c
La sortie montre que -- est passé comme argument à TestExe.
Arg 0 is <-a>
Arg 1 is <-b>
Arg 2 is <-->
Arg 3 is <-c>