Partager via


3. Concepts de base

3.1 Fournisseurs et lecteurs

Un fournisseur permet l’accès aux données et aux composants qui sans cela ne seraient pas facilement accessibles au niveau de la ligne de commande. Les données sont présentées dans un format cohérent qui ressemble à un lecteur du système de fichiers.

Les données exposées par un fournisseur apparaissent sur un lecteur, et les données sont accessibles via un chemin, tout comme avec un lecteur de disque. Les cmdlets intégrés pour chaque fournisseur gèrent les données sur le lecteur du fournisseur.

PowerShell comprend l’ensemble suivant de fournisseurs intégrés pour accéder aux différents types de magasins de données :

Fournisseur Nom du lecteur Description Référence
Alias Alias: Alias PowerShell §3.1.1
Environnement Env: Variables d'environnement §3.1.2
FileSystem A:, B:, C:, ... Lecteurs de disque, répertoires et fichiers §3.1.3
Fonction Fonction : Fonctions PowerShell §3.1.4
Variable Variable : Variables PowerShell §3.1.5

Windows PowerShell :

Fournisseur Nom du lecteur Description
Certificat Cert: Certificats x509 pour les signatures numériques
Registre HKLM: (HKEY_LOCAL_MACHINE), HKCU: (HKEY_CURRENT_USER) Registre Windows
WSMan WSMan : Informations de configuration de WS-Management

Les cmdlets suivantes concernent les fournisseurs et les lecteurs :

  • Get-PSProvider : Obtient des informations sur un ou plusieurs fournisseurs
  • Get-PSDrive : Obtient des informations sur un ou plusieurs lecteurs

Le type d’un objet qui représente un fournisseur est décrit dans §4.5.1. Le type d’un objet qui représente un lecteur est décrit dans §4.5.2.

3.1.1 Alias

Un alias est un nom alternatif pour une commande. Une commande peut avoir plusieurs alias, et le nom d’origine et tous ses alias peuvent être utilisés de façon interchangeable. Un alias peut être réaffecté. Un alias est un élément (§3.3).

Un alias peut être affecté à un autre alias ; cependant, le nouvel alias n’est pas un alias de la commande d’origine.

Le fournisseur Alias est un espace de noms plat qui contient seulement des objets qui représentent les alias. Les variables n'ont pas d'éléments enfants.

Certains alias sont intégrés à PowerShell.

Les cmdlets suivantes concernent les alias :

  • New-Alias : Crée un alias
  • Set-Alias : Crée ou modifie un ou plusieurs alias
  • Get-Alias : Obtient des informations sur un ou plusieurs alias
  • Export-Alias : Exporte un ou plusieurs alias dans un fichier

Quand un alias est créé pour une commande avec New-Alias, les paramètres de cette commande ne peuvent pas être inclus dans cet alias. Cependant, l’affectation directe à une variable dans l’espace de noms Alias: ne permet pas d’inclure des paramètres.

Notes

Il est cependant simple de créer une fonction qui ne fait rien d’autre que de contenir l’appel de cette commande avec tous les paramètres souhaités et d’affecter un alias à cette fonction.

Le type d’un objet qui représente un alias est décrit dans §4.5.4.

Les objets alias sont stockés sur le lecteur Alias: : (§3,1).

3.1.2 Variables d’environnement

Le fournisseur d’environnement PowerShell permet de récupérer, d’ajouter, de modifier, d’effacer et de supprimer les variables d’environnement du système d’exploitation.

Le fournisseur Environment est un espace de noms plat qui contient seulement des objets représentant les variables d’environnement. Les variables n'ont pas d'éléments enfants.

Le nom d’une variable d’environnement ne peut pas inclure le signe égal (=).

Les modifications apportées aux variables d'environnement affectent seulement la session active.

Une variable d’environnement est un élément (§3.3).

Le type d’un objet qui représente une variable d’environnement est décrit dans §4.5.6.

Les objets de variable d’environnement sont stockés sur le lecteur Env: (§3.1).

3.1.3 Système de fichiers

Le fournisseur de système de fichiers PowerShell permet de créer, d’ouvrir, de modifier et de supprimer des répertoires et des fichiers.

Le fournisseur de système de fichiers est un espace de noms hiérarchique qui contient des objets représentant le système de fichiers sous-jacent.

Les fichiers sont stockés sur des lecteurs avec des noms comme B:, C:, etc. (§3.1). Les répertoires et les fichiers sont accessibles via la notation des chemins (§3.4).

Un répertoire ou un fichier est un élément (§3.3).

3.1.4 Fonctions

Le fournisseur de fonctions PowerShell permet l’extraction, l’ajout, la modification, l’effacement et la suppression des fonctions (§8.10) et des filtres (§8.10.1).

Le fournisseur Function est un espace de noms plat qui contient seulement les objets de fonction et de filtre. Ni les fonctions ni les filtres n'ont des éléments enfants.

Les modifications apportées aux fonctions affectent seulement la session active.

Une fonction est un élément (§3.3).

Le type d’un objet qui représente une fonction est décrit dans §4.5.10. Le type d’un objet qui représente un filtre est décrit dans §4.5.11.

Les objets de fonction sont stockés sur le lecteur Function: (§3.1).

3.1.5 Variables

Les variables peuvent être définies et manipulées directement dans le langage PowerShell.

Le fournisseur Variable est un espace de noms plat qui contient seulement des objets représentant les variables. Les variables n'ont pas d'éléments enfants.

Les cmdlets suivantes agissent aussi sur les variables :

Comme une variable est un élément (§3.3), elle peut être manipulée par la plupart des cmdlets qui concernent les éléments.

Le type d’un objet qui représente une variable est décrit dans §4.5.3.

Les objets de variable sont stockés sur le lecteur Variable: (§3.1).

3.2 Emplacements de travail

L’emplacement de travail actif est l’emplacement par défaut vers lequel les commandes pointent. C’est l’emplacement utilisé si un chemin explicite (§3.4) n’est pas fourni quand une commande est appelée. Cet emplacement comprend le lecteur actif.

Un hôte PowerShell peut avoir plusieurs lecteurs, auquel cas chaque lecteur a son propre emplacement actif.

Quand un nom de lecteur est spécifié sans répertoire, l’emplacement actif pour ce lecteur est implicite.

L’emplacement de travail actif peut être enregistré sur une pile, puis défini sur un nouvel emplacement. Plus tard, cet emplacement enregistré peut être restauré à partir de cette pile et devenir l’emplacement de travail actif. Il existe deux types de piles d’emplacements : la pile d’emplacements de travail par défaut, et zéro, une ou plusieurs piles d’emplacements de travail nommées définies par l’utilisateur. Quand une session commence, la pile d’emplacements de travail par défaut est également la pile d’emplacements de travail active. Cependant, toute pile d’emplacements de travail nommée peut devenir la pile d’emplacements de travail active.

Les cmdlets suivantes concernent les emplacements :

  • Set-Location : Établit l’emplacement de travail actif
  • Get-Location : Détermine l’emplacement de travail actif pour le ou les lecteurs spécifiés, ou les emplacements de travail pour la ou les piles spécifiées
  • Push-Location : Enregistre l’emplacement de travail actif en haut d’une pile d’emplacements spécifiée
  • Pop-Location : Restaure l’emplacement de travail actif depuis le haut d’une pile d’emplacements spécifiée

Les types d’objets qui représentent un emplacement de travail et une pile d’emplacements de travail sont décrits dans §4.5.5.

3.3 Éléments

Un élément est un alias (§3.1.1), une variable (§3.1.5), une fonction (§3.1.4), une variable d’environnement (§3.1.2), ou un fichier ou un répertoire dans un système de fichiers (§3.1.3).

Les cmdlets suivantes concernent les éléments :

  • New-Item : Crée un élément
  • Set-Item : Modifie la valeur d’un ou plusieurs éléments
  • Get-Item : Obtient les éléments à l’emplacement spécifié
  • Get-ChildItem : Obtient les éléments les éléments enfants à l’emplacement spécifié
  • Copy-Item : Copie un ou plusieurs éléments d’un emplacement vers un autre
  • Move-Item : Déplace un ou plusieurs éléments d’un emplacement vers un autre
  • Rename-Item : Renomme un élément
  • Invoke-Item : Effectue l’action par défaut sur un ou plusieurs éléments
  • Clear-Item : Supprime le contenu d’un ou plusieurs éléments, mais ne supprime pas les éléments (consultez
  • Remove-Item : Supprime les éléments spécifiés

Les cmdlets suivantes concernent le contenu des éléments :

Le type d’un objet qui représente un répertoire est décrit dans §4.5.17. Le type d’un objet qui représente un fichier est décrit dans §4.5.18.

3.4 Noms de chemin

Tous les éléments d’un magasin de données accessibles via un fournisseur PowerShell peuvent être identifiés de façon univoque par leurs noms de chemin. Un nom de chemin est une combinaison du nom de l’élément, du conteneur et des sous-conteneurs où se trouve l’élément, et du lecteur PowerShell via lequel les conteneurs sont accessibles.

Les noms de chemin appartiennent à un des deux types suivants : complet et relatif. Un nom de chemin complet est constitué de tous les éléments qui composent un chemin. La syntaxe suivante montre les éléments d’un nom de chemin complet :

Conseil

La notation ~opt~ dans les définitions de syntaxe indique que l’entité lexicale est facultative dans la syntaxe.

path:
    provider~opt~   drive~opt~   containers~opt~   item

provider:
    module~opt~   provider   ::

module:
    module-name   \

drive:
    drive-name   :

containers:
    container   \
    containers container   \

module-name fait référence au module parent.

provider fait référence au fournisseur PowerShell qui permet l’accès au magasin de données.

drive fait référence au lecteur PowerShell qui est pris en charge par un fournisseur PowerShell particulier.

Un conteneur peut contenir d’autres conteneurs, qui peuvent eux-mêmes contenir d’autres conteneurs, et ainsi de suite, le conteneur final contenant un élément. Les conteneurs doivent être spécifiés dans l’ordre hiérarchique où ils se trouvent dans le magasin de données.

Voici un exemple de nom de chemin :

E:\Accounting\InvoiceSystem\Production\MasterAccount\MasterFile.dat

Si l’élément final d’un chemin contient d’autres éléments, c’est un élément conteneur ; sinon, c’est un élément feuille.

Dans certains cas, un nom de chemin complet n’est pas nécessaire : un nom de chemin relatif suffit. Un nom de chemin relatif est basé sur l’emplacement de travail actif. PowerShell permet d’identifier un élément en fonction de son emplacement par rapport à l’emplacement de travail actif. Un nom de chemin relatif implique l’utilisation de certains caractères spéciaux. Le tableau suivant décrit chacun de ces caractères et fournit des exemples de noms de chemins relatifs et de noms de chemins complets. Les exemples du tableau sont basés sur un répertoire de travail actif défini sur C:\Windows :

Symbole Description Chemin relatif Nom de chemin complet
. Emplacement de travail actif .\System C:\Windows\System
.. Parent de l’emplacement de travail actif ..\Program Files C:\Program Files
\ Racine du lecteur de l’emplacement de travail actif \Program Files C:\Program Files
Aucun Pas de caractères spéciaux System C:\Windows\System

Pour utiliser un nom de chemin dans une commande, entrez ce nom sous la forme d’un nom de chemin complet ou relatif.

Les cmdlets suivantes concernent les chemins :

  • Convert-Path : Convertit un chemin d’un chemin PowerShell en chemin de fournisseur PowerShell
  • Join-Path : Combine un chemin et un chemin enfant en un seul chemin
  • Resolve-Path : Résout les caractères génériques en un chemin
  • Split-Path : Retourne la partie spécifiée d’un chemin
  • Test-Path : Détermine si les éléments d’un chemin existent ou si un chemin est correctement construit

Certaines cmdlets (comme Add-Content et Copy-Item) utilisent des filtres de fichiers. Un filtre de fichiers est un mécanisme permettant de spécifier les critères de sélection à partir d’un ensemble de chemins.

Le type d’objet qui représente un chemin résolu est décrit dans §4.5.5. Les chemins sont souvent manipulés en tant que chaînes.

3.5 Étendues

3.5.1 Introduction

Un nom peut désigner une variable, une fonction, un alias, une variable d’environnement ou un lecteur. Le même nom peut désigner des éléments différents à des emplacements différents dans un script. Pour chaque élément différent désigné par un nom, ce nom est visible seulement dans la région du texte du script qui est appelée son étendue. Les différents éléments désignés par le même nom ont des étendues différentes ou se trouvent dans des espaces de noms différents.

Les étendues peuvent s’imbriquer, auquel cas une étendue externe est appelée étendue parente, et toutes les étendues imbriquées sont des étendues enfants de ce parent. L’étendue d’un nom est l’étendue dans laquelle il est défini et toutes les étendues enfants, sauf s’il est rendu privé. Dans une étendue enfant, un nom qui y est défini contient les éléments définis avec le même nom dans les étendues parentes.

À moins que la notation de type « dot-sourcing » (§ 3.5.5) soit utilisée, chacun des éléments suivants crée une étendue :

  • Un fichier de script
  • Un bloc de script
  • Une fonction ou un filtre

Prenons l’exemple suivant :

# start of script
$x = 2; $y = 3
Get-Power $x $y

#function defined in script

function Get-Power([int]$x, [int]$y)
{
if ($y -gt 0) { return $x * (Get-Power $x (--$y)) }

else { return 1 }
}
# end of script

L’étendue des variables $x et $y créées dans le script est le corps de ce script, y compris la fonction qui y est définie. La fonction Get-Power définit deux paramètres avec ces mêmes noms. Chaque fonction ayant sa propre étendue, ces variables sont différentes de celles définies dans l’étendue parente et elles les masquent à l’étendue parente. L’étendue de la fonction est imbriquée dans l’étendue du script.

Notez que la fonction s’appelle elle-même récursivement. Chaque fois qu’elle le fait, elles crée une autre étendue imbriquée, chacune avec ses propres variables $x et $y.

Voici un exemple plus complexe, qui montre aussi des étendues imbriquées et la réutilisation de noms :

# start of script scope
$x = 2              # top-level script-scope $x created
                    # $x is 2
F1                  # create nested scope with call to function F1
                    # $x is 2
F3                  # create nested scope with call to function F3
                    # $x is 2

function F1 {       # start of function scope
                    # $x is 2
    $x = $true      # function-scope $x created
                    # $x is $true

    & {             # create nested scope with script block
                    # $x is $true
        $x = 12.345 # scriptblock-scope $x created
                    # $x is 12.345
    }               # end of scriptblock scope, local $x goes away

                    # $x is $true
    F2              # create nested scope with call to function F2
                    # $x is $true
}                   # end of function scope, local $x goes away

function F2 {       # start of function scope
                    # $x is $true
    $x = "red"      # function-scope $x created
                    # $x is "red"
}                   # end of function scope, local $x goes away

function F3 {       # start of function scope
                    # $x is 2
    if ($x -gt 0) {
                    # $x is 2
        $x = "green"
                    # $x is "green"
    }               # end of block, but not end of any scope
                    # $x is still "green"
}                   # end of function scope, local $x goes away
# end of script scope

3.5.2 Noms et numéros des étendues

PowerShell prend en charge les étendues suivantes :

  • Globale : C’est l’étendue du niveau le plus élevé. Toutes les variables automatiques et de préférence sont définies dans cette étendue. La portée globale est l’étendue parente de toutes les autres étendues, et toutes les autres étendues sont des étendues enfants de l’étendue globale.

  • Locale : C’est l’étendue active à n’importe quel point d’exécution au sein d’un script, d’un bloc de script ou d’une fonction. Toute étendue peut être l’étendue locale.

  • Script : Cette étendue existe pour chaque fichier de script qui est exécuté. L’étendue de script est l’étendue parente de toutes les étendues créées à partir de celui-ci. Un bloc de script n’a pas sa propre étendue de script ; au lieu de cela, son étendue de script est celle de son fichier de script ancêtre le plus proche. Bien que quelque chose comme une étendue de module n’existe pas, l’étendue de script en fournit l’équivalent.

Les noms peuvent être déclarés comme étant privés, auquel cas ils ne sont pas visibles en dehors de leur étendue parente, même pas pour les étendues enfants. Le concept de « privé » n’est pas une étendue distincte ; c’est un alias pour l’étendue locale avec en plus le masquage du nom s’il est utilisé comme emplacement accessible en écriture.

Les étendues peuvent être référencées par un numéro, qui décrit la position relative d’une étendue par rapport à une autre. L’étendue 0 indique l’étendue locale, l’étendue 1 indique une étendue ancêtre de génération 1, l’étendue 2 indique une étendue ancêtre de génération 2, etc. (Les numéros d’étendue sont utilisés par les cmdlets qui manipulent des variables.)

3.5.3 Étendue des noms de variable

Comme le montre la production suivante, un nom de variable peut être spécifié avec une des six étendues différentes :

variable-scope:
    global:
    local:
    private:
    script:
    using:
    workflow:
    variable-namespace

L’étendue est facultative. Le tableau suivant montre la signification de chacune dans tous les contextes possibles. Il montre aussi l’étendue quand aucune étendue n’est spécifiée explicitement :

Modificateur d’étendue Dans un fichier de script Dans un bloc de script Dans une fonction
globale Étendue globale Étendue globale Étendue globale
script Étendue du fichier de script ancêtre le plus proche ou Globale s’il n’existe pas de fichier de script ancêtre le plus proche Étendue du fichier de script ancêtre le plus proche ou Globale s’il n’existe pas de fichier de script ancêtre le plus proche Étendue du fichier de script ancêtre le plus proche ou Globale s’il n’existe pas de fichier de script ancêtre le plus proche
private Étendue globale/de script/locale Étendue locale Étendue locale
local Étendue globale/de script/locale Étendue locale Étendue locale
using Défini par l’implémentation Défini par l’implémentation Défini par l’implémentation
flux de travail Défini par l’implémentation Défini par l’implémentation Défini par l’implémentation
Aucun Étendue globale/de script/locale Étendue locale Étendue locale

Des informations sur l’étendue des variables peuvent également être spécifiées lors de l’utilisation de la famille de cmdlets listées dans (§3.1.5). En particulier, reportez-vous au paramètre Scope, et aux paramètres Option Private et Option AllScope pour plus d’informations.

L’étendue using est utilisée pour accéder aux variables définies dans une autre étendue lors de l’exécution de scripts via des cmdlets comme Start-Job ou Invoke-Command, ou dans une instruction InlineScript (inlinescript-statement). Par exemple :

$a = 42
Invoke-Command --ComputerName RemoteServer { $using:a } # returns 42
workflow foo
{
    $b = "Hello"
    inlinescript { $using:b }
}
foo # returns "Hello"

Le workflow d’étendue est utilisé avec une instruction parallèle (parallel-statement) ou une instruction en séquence (sequence-statement) pour accéder à une variable définie dans le workflow.

3.5.4 Étendue des noms de fonction

Un nom de fonction peut également avoir une des quatre étendues différentes, et la visibilité de ce nom est la même que pour les variables (§3.5.3).

3.5.5 Notation de type « dot-sourcing »

Quand un fichier de script, un bloc de script ou une fonction est exécuté depuis un autre fichier de script, un autre bloc de script ou une autre fonction, le fichier de script exécuté crée une étendue imbriquée. Par exemple,

Script1.ps1
& "Script1.ps1"
& { ... }
FunctionA

Cependant, quand la notation de type « dot-sourcing » est utilisée, aucune nouvelle étendue n’est créée avant l’exécution de la commande : les ajouts/modifications qu’elle aurait dû faire à sa propre étendue locale sont effectués à la place sur l’étendue active. Par exemple,

. Script2.ps1
. "Script2.ps1"
. { ... }
. FunctionA

3.5.6 Modules

Comme un fichier de script du plus haut niveau est à la racine d’une arborescence hiérarchique d’étendues imbriquées, il en va de même pour chaque module (§3.14). Cependant, par défaut, seuls les noms exportés par un module sont disponibles via leur nom à partir du contexte d’importation. Le paramètre global de la cmdlet Import-Module permet aux noms exportés d’avoir une visibilité accrue.

3.6 Propriétés ReadOnly et Constant

Les variables et les alias sont décrits par des objets qui contiennent un certain nombre de propriétés. Ces propriétés sont définies et manipulées par deux familles d’applets de commande (§3.1.5, §3.1.1). Une de ces propriétés est Options, qui peut être définie sur ReadOnly ou sur Constant (en utilisant le paramètre Option). Une variable ou un alias marqué ReadOnly peut être supprimé et ses propriétés peuvent être modifiées, à condition que le paramètre Force soit spécifié. Cependant, une variable ou un alias marqué Constant ne peut pas être supprimé et ses propriétés ne peuvent pas être modifiées.

3.7 Surcharges de méthode et résolution des appels

3.7.1 Introduction

Comme indiqué dans §1, une procédure externe rendue disponible par l’environnement d’exécution (et écrite dans un langage autre que PowerShell) est appelée méthode.

Le nom d’une méthode ainsi que le nombre et les types de ses paramètres sont collectivement appelés la signature de cette méthode. (Notez que la signature n’inclut pas le type de retour de la méthode.) L’environnement d’exécution peut permettre à un type d’avoir plusieurs méthodes portant le même nom, à condition que chacune ait une signature différente. Quand plusieurs versions d’une méthode sont définies, cette méthode est dite surchargée. Par exemple, le type Math (§4.3.8) contient un ensemble de méthodes appelées Abs, qui calcule la valeur absolue d’un nombre spécifié, où le nombre spécifié peut avoir différents types. Les méthodes de cet ensemble ont les signatures suivantes :

Abs(decimal)
Abs(float)
Abs(double)
Abs(int)
Abs(long)
Abs(SByte)
Abs(Int16)

Dans ce cas, toutes les méthodes ont le même nombre d’arguments ; leurs signatures diffèrent seulement par le type d’argument.

Un autre exemple concerne le type tableau (Array) (§4.3.2), qui contient un ensemble de méthodes nommées Copy, qui copie une plage d’éléments d’un tableau dans un autre, en commençant au début de chaque tableau (par défaut) ou à un élément désigné. Les méthodes de cet ensemble ont les signatures suivantes :

Copy(Array, Array, int)
Copy(Array, Array, long)
Copy(Array, int, Array, int, int)
Copy(Array, long, Array, long, long)

Dans ce cas, les signatures diffèrent par le type d’argument et, dans certains cas, aussi par le nombre d’arguments.

Dans la plupart des appels à des méthodes surchargées, le nombre et le type des arguments passés correspondent exactement à une des surcharges, et la méthode sélectionnée est évidente. Cependant, si ce n’est pas le cas, il doit exister un moyen de décider de la version surchargée à appeler (si elle existe). Par exemple,

[Math]::Abs([byte]10) # no overload takes type byte
[Array]::Copy($source, 3, $dest, 5L, 4) # both int and long indexes

Le type chaîne (c’est-à-dire System.String), qui a de nombreuses méthodes surchargées, est un autre exemple.

Bien que PowerShell dispose de règles pour résoudre les appels de méthode qui ne correspondent pas exactement à une signature surchargée, il n’offre pas lui-même un moyen de définir des méthodes surchargées.

Notes

Remarque du rédacteur : PowerShell 5.0 a ajouté la possibilité de définir des classes basées sur des scripts. Ces classes peuvent contenir des méthodes surchargées.

3.7.2 Résolution des méthodes surchargées

Dans le cas d’un appel de méthode (§ 7.1.3) ayant une liste d’expressions d’arguments et un ensemble de méthodes candidates (c’est-à-dire des méthodes qui pourraient être appelées), le mécanisme de sélection de la meilleure méthode est appelé résolution de la surcharge.

Compte tenu de l’ensemble des méthodes candidates applicables (§3.7.3), la meilleure méthode de cet ensemble est sélectionnée. Si l’ensemble ne contient qu’une seule méthode, cette méthode est la meilleure méthode. Dans le cas contraire, la meilleure méthode est celle qui est meilleure que toutes les autres méthodes quant à la liste d’arguments donnée, selon les règles indiquées dans §3.7.4. S’il n’y a pas exactement une méthode qui est mieux que toutes les autres méthodes, l’appel de la méthode est ambigu et une erreur est signalée.

La meilleure méthode doit être accessible dans le contexte où elle est appelée. Par exemple, un script PowerShell ne peut pas appeler une méthode qui est privée ou protégée.

La meilleure méthode pour un appel à une méthode statique doit être une méthode statique, et la meilleure méthode pour un appel à une méthode d’instance doit être une méthode d’instance.

3.7.3 Méthode applicable

Une méthode est dite applicable relativement à une liste d’arguments a quand une des conditions suivantes est vraie :

  • Le nombre d’arguments dans A est identique au nombre de paramètres que la méthode accepte.
  • La méthode a M paramètres obligatoires et N paramètres facultatifs, et le nombre d’arguments dans A est supérieur ou égal à M, mais inférieur à N.
  • La méthode accepte un nombre variable d’arguments et le nombre d’arguments dans A est supérieur au nombre de paramètres que la méthode accepte.

En plus de l’obligation d’un nombre approprié d’arguments, chaque argument dans A doit correspondre au mode de passage de paramètre de l’argument, et le type de l’argument doit correspondre au type du paramètre, ou bien il doit y avoir une conversion du type de l’argument vers le type du paramètre.

Si le type d’argument est ref (§4.3.6), le paramètre correspondant doit également être ref, et le type d’argument pour la conversion est le type de la propriété Valeur de l’argument ref.

Si le type d’argument est ref, le paramètre correspondant peut être out au lieu de ref.

Si la méthode accepte un nombre variable d’arguments, la méthode peut être applicable dans une forme normale ou une forme développée. Si le nombre d’arguments dans A est identique au nombre de paramètres acceptés par la méthode et que le dernier paramètre est un tableau, le formulaire dépend du rang de l’une des deux conversions possibles :

  • Le rang de la conversion du type du dernier argument dans A vers le type tableau pour le dernier paramètre.
  • Le rang de la conversion du type du dernier argument dans A vers le type d’élément du type tableau pour le dernier paramètre.

Si la première conversion (vers le type tableau) est meilleure que la deuxième conversion (vers le type d’élément du tableau), la méthode s’applique dans la forme normale, sinon elle s’applique dans la forme développée.

S’il y a plus d’arguments que de paramètres, la méthode peut s’appliquer seulement dans forme développée. Pour être applicable dans la forme développée, le dernier paramètre doit être du type tableau. La méthode est remplacée par une méthode équivalente où le dernier paramètre est remplacé par des paramètres suffisants pour tenir compte de chaque argument sans correspondance dans A. Chaque type de paramètre supplémentaire est le type d’élément du type tableau pour le dernier paramètre dans la méthode d’origine. Les règles ci-dessus pour une méthode applicable sont appliquées à cette nouvelle méthode et à la liste d’arguments A.

3.7.4 Meilleure méthode

Étant donné une liste d’arguments A avec un ensemble d’expressions d’argument { E~1~, E~2~, ..., E~N~ } et deux méthodes d’application M~P~ et M~Q~ avec des types de paramètre { P~1~, P~2~, ..., P~N~ } et { Q~1~, Q~2~, ..., Q~N~ }, M~P~ est défini comme meilleure méthode que M~Q~ si le classement cumulatif des conversions pour M~P~ est meilleur que pour M~Q~.

Le classement cumulatif des conversions est calculé comme suit. Chaque conversion a une valeur différente selon le nombre de paramètres, avec la conversion de E~1~ valant N, E~2~ valant N-1, jusqu’à E~N~ valant 1. Si la conversion de E~X~ en P~X~ est meilleure que celle de E~X~ en Q~X~, M~P~ est le résultat de N-X+1 ; sinon, M~Q~ est le résultat de N-X+1. Si M~P~ et M~Q~ ont la même valeur, les règles de départage suivantes sont utilisées, appliquées dans l’ordre :

  • Le classement cumulé des conversions entre les types de paramètre (en ignorant les types d’argument) est calculé de façon similaire au classement précédent : P~1~ est comparé à Q~1~, P~2~ est comparé à Q~2~, ..., et P~N~ est comparé à Q~N~. La comparaison est ignorée si l’argument était $null, ou si les types de paramètre ne sont pas des types numériques. La comparaison est également ignorée si la conversion de l’argument E~X~ perd des informations quand il est converti en P~X~, mais ne perd pas d’informations quand il est converti en Q~X~, ou vice versa. Si les types de conversion de paramètre sont comparés, si la conversion de P~X~ en Q~X~ est meilleure que celle de Q~X~ en P~X~, M~P~ est résultat de accumule N-X+1 ; sinon, M~Q~ est le résultat de N-X+1. Cette règle de départage est conçue pour préférer la méthode la plus spécifique (c’est-à-dire la méthode avec des paramètres ayant les types de données les plus petits) si aucune information n’est perdue dans les conversions, ou pour préférer la méthode la plus générale (c’est-à-dire la méthode avec les paramètres ayant les types de données les plus grands) si les conversions entraînent une perte d’informations.
  • Si les deux méthodes utilisent leur forme développée, la méthode ayant le plus de paramètres est la meilleure méthode.
  • Si une méthode utilise la forme développée et que l’autre utilise la forme normale, la méthode utilisant la forme normale est la meilleure méthode.

3.7.5 Meilleure conversion

Le texte ci-dessous marqué de cette façon est spécifique à Windows PowerShell.

Les conversions sont classées de la façon suivante, du plus bas au plus haut :

  • T~1~[] en T~2~[] où il n’existe pas de conversion attribuable entre T~1~ et T~2~
  • T en chaîne, où T est n’importe quel type
  • T~1~ en T~2~, où T~1~ ou T~2~ définissent une conversion personnalisée d’une façon définie par l’implémentation
  • T~1~ en T~2~, où T~1~ implémente IConvertible
  • T~1~ en T~2~, où T~1~ ou T~2~ implémente la méthode T~2~ op_Implicit(T1)
  • T~1~ en T~2~, où T~1~ ou T~2~ implémente la méthode T~2~ op_Explicit(T1)
  • T~1~ en T~2~, où T~2~ implémente un constructeur prenant un seul argument de type T~1~
  • Une des conversions suivantes :
    • string en T, où T implémente une méthode statique T Parse(string) ou T Parse(string, IFormatProvider)
    • T~1~ en T~2~, où T~2~ est un enum et T~1~ est une chaîne ou une collection d’objets qui peut être convertie en chaîne
  • T en PSObject, où T est un type quelconque
  • Une des conversions suivantes : Language
    • T en booléen, où T est un type numérique
    • chaîne en T, où T est regex, wmisearcher, wmi, wmiclass, adsi, adsisearcher ou type
    • Il lance T sur bool.
    • T~1~ en Nullable[T~2~], où il existe une conversion de T~1~ en T~2~
    • T en void
    • T~1~[] en T~2~[], où il existe une conversion attribuable entre T~1~ et T~2~
    • T~1~ en T~2~[], où T~1~ est une collection
    • Il lance IDictionary sur Hashtable.
    • Il lance T sur ref.
    • Il lance T sur xml.
    • Il lance scriptblock sur delegate.
    • T~1~ en T~2~, où T~1~ est un type entier et T~2~ est un enum
  • $null en T, où T est n’importe quel type de valeur
  • $null en T, où T est n’importe quel type de référence
  • Une des conversions suivantes :
    • octet en T, où T est SByte

    • UInt16 en T, où T est SByte, byte ou Int16

    • Int16 en T, où T est SByte ou byte

    • UInt32 en T, où T est SByte, byte, Int16, UInt16 ou int

    • int en T, où T est SByte, byte, Int16 ou UInt16

    • UInt64 en T, où T est SByte, byte, Int16, UInt16, int, UInt32 ou long

    • long en T, où T est SByte, byte, Int16, UInt16, int ou UInt32

    • float en T, où T est un type entier ou decimal

    • double en T, où T est un type entier ou decimal

    • decimal en T, où T est un type entier

  • Une des conversions suivantes :
    • SByte en T, où T est byte, uint6, UInt32 ou UInt64
    • Int16 en T, où T est UInt16, UInt32 ou UInt64
    • int en T, où T est UInt32 ou UInt64
    • Il lance long sur UInt64.
    • decimal en T, où T est float ou double
  • Une des conversions suivantes :
    • T en string, où T est un type numérique
    • T en char, où T est un type numérique
    • string en T, où T est un type numérique
  • Un des conversions suivantes, qui sont considérées comme des conversions attribuables :
    • byte en T, où T est Int16, UInt16, int, UInt32, long, UInt64, single, double ou decimal
    • SByte en T, où T est Int16, UInt16, int, UInt32, long, UInt64, single, double ou decimal
    • UInt16 en T, où T est int, UInt32, long, ou UInt64, single, double ou decimal
    • Int16 en T, où T est int, UInt32, long, ou UInt64, single, double ou decimal
    • UInt32 en T, où T est long, ou UInt64, single, double ou decimal
    • int en T, où T est long, UInt64, single, double ou decimal
    • Il lance single sur double.
  • T~1~ en T~2~, où T~2~ est une classe de base ou une interface de T~1~. Cette conversion est considérée comme une conversion attribuable.
  • Il lance string sur char[].
  • T en T : cette conversion est considérée comme une conversion attribuable.

Pour chaque conversion de la forme T~1~ en T~2~[], où T~1~ n’est pas un tableau et où aucune autre conversion ne s’applique, s’il y a une conversion de T~1~ en T~2~, le rang de la conversion est plus mauvais que la conversion de T~1~ en T~2~, mais meilleur que n’importe quelle conversion classée en deçà de la conversion de T~1~ en T~2~

3.8 Recherche de nom

Il est possible d’avoir des commandes de différentes sortes portant toutes le même nom. Dans ce cas, l’ordre dans lequel la recherche de nom est effectuée est : alias, fonction, cmdlet et commande externe.

3.9 Recherche de nom de type

§7.1.10 contient l’indication « Un type-literal est représenté dans une implémentation par un type sous-jacent non spécifié. Par conséquent, un nom de type est un synonyme pour son type sous-jacent. » int, double, long[] et Hashtable sont des exemples de type.

Les noms de types sont mis en correspondance comme suit : comparer un nom de type donné avec la liste des accélérateurs de type intégrés, comme int, long, double. Si une correspondance est trouvée, c’est le type. Sinon, supposer que le nom du type est complètement qualifié et vérifier si un tel type existe sur le système hôte. Si une correspondance est trouvée, c’est le type. Sinon, ajouter le préfixe d’espace de noms System.. Si une correspondance est trouvée, c’est le type. Sinon, le nom du type est une erreur. Cet algorithme est appliqué pour chaque argument de type pour les types génériques. Cependant, il n’est pas nécessaire de spécifier l’arité (le nombre d’arguments ou d’opérandes pris par une fonction ou un opérateur).

3.10 Gestion automatique de la mémoire

Différents opérateurs et cmdlets entraînent l’allocation de mémoire pour les objets de type de référence, comme les chaînes et les tableaux. L’allocation et la libération de cette mémoire sont gérées par le système du runtime PowerShell. Autrement dit, PowerShell fournit un nettoyage de la mémoire automatique.

3.11 Ordre d’exécution

Un effet secondaire est une modification de l’état de l’environnement d’exécution d’une commande. Une modification apportée à la valeur d’une variable (via les opérateurs d’affectation ou les opérateurs de pré/post incrémentation/décrémentation) est un effet secondaire, tout comme la modification du contenu d’un fichier.

Sauf spécification contraire, les instructions sont exécutées dans l’ordre lexical.

À l’exception de ce qui est spécifié pour certains opérateurs, l’ordre d’évaluation des termes dans une expression et l’ordre dans lequel les effets secondaires ont lieu ne sont pas spécifiés.

Une expression qui appelle une commande implique l’expression qui désigne la commande, et zéro, une ou plusieurs expressions qui désignent les arguments dont les valeurs doivent être passées à cette commande. L’ordre dans lequel ces expressions sont évaluées les unes par rapport aux autres n’est pas spécifié.

3.12 Gestion des erreurs

Quand une commande échoue, c’est considéré comme une erreur et les informations sur cette erreur sont enregistrées dans un enregistrement d’erreur dont le type n’est pas spécifié (§4.5.15) ; cependant , ce type prend en charge les indices.

Une erreur appartient à l’une ou l’autre des deux catégories suivantes. Elle met fin à l’opération (une erreur avec fin d’exécution) ou elle n’y met pas fin (une erreur sans fin d’exécution). Avec une erreur avec fin d’exécution, l’erreur est enregistrée et l’opération s’arrête. Avec une erreur sans fin d’exécution, l’erreur est enregistrée et l’opération continue.

Les erreurs sans fin d’exécution sont écrites dans le flux d’erreurs. Bien que ces informations puissent être redirigées vers un fichier, les objets d’erreur sont d’abord convertis en chaînes et les informations importantes dans ces objets ne sont pas capturées, ce qui rend les diagnostics difficiles, si ce n’est impossible. Au lieu de cela, le texte des erreurs peut être redirigé (§7,12) et l’objet d’erreur enregistré dans une variable, comme dans $Error1 = command 2>&1.

La variable automatique $Error contient une collection d’enregistrements d’erreur qui représentent des erreurs récentes, l’erreur la plus récente se trouvant dans ($Error[0]). Cette collection est conservée dans une mémoire tampon, les anciens enregistrements étant supprimés quand de nouveaux sont ajoutés. La variable automatique $MaximumErrorCount contrôle le nombre d’enregistrements qui peuvent être stockés.

$Error contient toutes les erreurs de toutes les commandes placées dans une même collection. Pour collecter les erreurs d’une commande spécifique, utilisez le paramètre commun ErrorVariable, qui permet de spécifier une variable définie par l’utilisateur pour contenir la collection.

3.13 Pipelines

Un pipeline est une série d’une ou plusieurs commandes séparées par l’opérateur de pipeline | (U+007C). Chaque commande reçoit une entrée de son prédécesseur et écrit la sortie pour son successeur. À moins que la sortie de la fin du pipeline soit ignorée ou redirigée vers un fichier, elle est envoyée à l’environnement hôte, qui peut choisir de l’écrire sur la sortie standard. Les commandes d’un pipeline peuvent également recevoir une entrée provenant d’arguments. Par exemple, considérez l’utilisation suivante des commandes Get-ChildItem, Sort-Object et Process-File, qui créent une liste de noms de fichiers dans un répertoire donné du système de fichiers, trient un ensemble d’enregistrements texte et effectuent un traitement sur un enregistrement texte, respectivement :

Get-ChildItem
Get-ChildItem e:*.txt | Sort-Object -CaseSensitive | Process-File >results.txt

Dans le premier cas, Get-ChildItem crée une collection de noms des fichiers du répertoire actif/par défaut. Cette collection est envoyée à l’environnement hôte qui, par défaut, écrit la valeur de chaque élément sur la sortie standard.

Dans le deuxième cas, Get-ChildItem crée une collection des noms des fichiers dans le répertoire spécifié, en utilisant l’argument e:*.txt. Cette collection est écrite pour la commande Sort-Object qui, par défaut, les trie par ordre croissant, en respectant la casse (en vertu de l’argument CaseSensitive). La collection résultante est ensuite écrite pour la commande Process-File, qui effectue un certain traitement (non connu). La sortie de cette commande est ensuite redirigée vers le fichier results.txt.

Si une commande écrit un objet individuel, son successeur reçoit cet objet, puis se termine après avoir écrit son ou ses propres objets pour son successeur. Cependant, si une commande écrit plusieurs objets, ceux-ci sont délivrés un à la fois à la commande qui lui succède, laquelle s’exécute une fois par objet. Ce comportement est appelé streaming. Dans le traitement des flux, les objets sont écrits dans le pipeline dès qu’ils deviennent disponibles, et non pas quand l’ensemble de la collection a été produit.

Lors du traitement d’une collection, une commande peut être écrite de telle sorte qu’elle puisse effectuer un traitement spécial avant l’élément initial et après l’élément final.

3.14 Modules

Un module est une unité réutilisable autonome qui permet de partitionner, d’organiser et d’abstraire du code PowerShell. Un module peut contenir des commandes (comme des cmdlets et des fonctions) et des éléments (comme des variables et des alias), qui peuvent être utilisés comme une même unité.

Une fois qu’un module a été créé, il doit être importé dans une session avant que les commandes et les éléments qu’il contient puissent être utilisés. Une fois qu’il est importé, les commandes et les éléments se comportent comme s’ils étaient définis localement. Un module est importé explicitement avec la commande Import-Module. Un module peut également être importé automatiquement comme déterminé d’une façon définie par une implémentation.

Le type d’un objet qui représente un fichier est décrit dans §4.5.12.

Les modules sont décrits en détail dans §11.

3.15 Expressions génériques

Une expression générique peut contenir zéro, un ou plusieurs des éléments suivants :

Élément Description
Caractère autre que *, ? ou [ Correspond à ce caractère
* Correspond à zéro, un ou plusieurs caractères. Pour établir une correspondance avec un caractère *, utilisez [*].
? Représente n'importe quel caractère. Pour établir une correspondance avec un caractère ?, utilisez [?].
[ensemble]

Établit une correspondance avec un des caractères de ensemble, qui ne peut pas être vide.

Si ensemble commence par ], ce crochet droit est considéré comme faisant partie de ensemble et le crochet droit suivant clôt l’ensemble ; sinon, le premier crochet droit clôt l’ensemble.

Si ensemble commence ou se termine par -, ce trait d’union/moins est considéré comme faisant partie de ensemble ; sinon, il indique une plage de points de code Unicode consécutifs avec les caractères de part et d’autre du trait d’union/moins comme délimiteurs de la plage inclusive. Par exemple, A-Z indique les 26 lettres majuscules de l’alphabet anglais et 0-9 indique les 10 chiffres décimaux.

Notes

Pour plus d’informations, consultez The Open Group Base Specifications: Pattern Matching", IEEE Std 1003.1, 2004 Edition. Cependant, dans PowerShell, le caractère d’échappement est l’accent grave et non pas la barre oblique inverse.

3.16 Expressions régulières

Une expression régulière peut contenir zéro, un ou plusieurs des éléments suivants :

Élément Description
Caractère autre que , [, ^, *, $, ou \ Correspond à ce caractère
. Représente n'importe quel caractère. Pour établir une correspondance avec un caractère « . », utilisez \..
[ensemble]
[^ensemble]

La forme [ensemble] établit une correspondance avec n’importe quel caractère d’un ensemble. La forme [^ensemble] établit une correspondance avec n’importe quel caractère qui n’est pas dans ensemble. ensemble ne peut pas être vide.

Si ensemble commence par ] ou par ^], ce crochet droit est considéré comme faisant partie de ensemble et le crochet droit suivant clôt l’ensemble ; sinon, le premier crochet droit clôt l’ensemble.

Si ensemble commence par - ou par ^, ou se termine par -, ce trait d’union/moins est considéré comme faisant partie de ensemble ; sinon, il indique une plage de points de code Unicode consécutifs avec les caractères de part et d’autre du trait d’union/moins comme délimiteurs de la plage inclusive. Par exemple, A-Z indique les 26 lettres majuscules de l’alphabet anglais et 0-9 indique les 10 chiffres décimaux.

* Correspond à zéro ou plusieurs occurrences de l’élément précédent.
+ Correspond à une ou plusieurs occurrences de l’élément précédent.
? Correspond à zéro ou une occurrence de l’élément précédent.
^ Correspond au début de la chaîne. Pour établir une correspondance avec un caractère ^, utilisez \^.
$ Correspond à la fin de la chaîne. Pour établir une correspondance avec un caractère $, utilisez $.
\c Place en échappement le caractère c : il n’est pas reconnu en tant qu’élément d’une expression régulière.

Windows PowerShell : les classes de caractères disponibles dans les expressions régulières de Microsoft .NET Framework sont prises en charge, comme suit :

Élément Description
\p{name} Correspond à n’importe quel caractère de la classe de caractères nommée spécifiée par name. Les noms pris en charge sont les groupes Unicode et les plages de blocs comme Ll, Nd, Z, IsGreek et IsBoxDrawing.
\P{name} Correspond au texte qui n’est pas inclus dans les groupes et les plages de blocs spécifiés dans name.
\w Correspond à n’importe quel caractère alphabétique. Équivalent aux catégories de caractères Unicode [\p{Ll}\p{Lu}\p{Lt}\p{Lo}\p{Nd}\p{Pc}]. Si un comportement conforme à ECMAScript est spécifié avec l’option ECMAScript, \w est équivalent à [a-zA-Z_0-9].
\W Correspond à tout caractère autre qu’un caractère de mot. Équivalent aux catégories Unicode [\^\p{Ll}\p{Lu}\p{Lt}\p{Lo}\p{Nd}\p{Pc}].
\s Correspond à n’importe quel espace. Équivalent aux catégories de caractères Unicode [\f\n\r\t\v\x85\p{Z}].
\S Correspond à tout caractère autre qu’un espace blanc. Équivalent aux catégories de caractères Unicode [\^\f\n\r\t\v\x85\p{Z}].
\d Correspond à n’importe quel chiffre décimal. Équivalent à \p{Nd} pour Unicode et à [0-9] pour un comportement non-Unicode.
\D Correspond à n’importe quel caractère autre qu’un chiffre. Équivalent à \P{Nd} pour Unicode et à [\^0-9] pour un comportement non-Unicode.

Les quantificateurs disponibles dans les expressions régulières de Microsoft .NET Framework sont pris en charge, comme suit :

Élément Description
* Spécifie zéro correspondance ou plus ; par exemple, \w* ou (abc)*. sont équivalents à {0,}.
+ Correspond à des instances répétées des caractères précédents.
? Spécifie zéro ou une correspondance ; par exemple, \w? ou (abc)?. Équivaut à {0,1}.
{n} Spécifie exactement n correspondances ; par exemple, (pizza){2}.
{n,} Spécifie au moins n correspondances ; par exemple, (abc){2,}.
{n,m} Spécifie au moins n mais pas plus de m correspondances.