Variables et types de données

Les variables

$variable = valeur d'un type quelconque
 

Les constantes

Les constantes sont des variables dont le contenu ne doit (et/ou ne peut) pas changer au cours du temps.

Bien qu’il soit possible de se contenter d’une simple affectation de variable, cette technique n’empêche pas une éventuelle modification du contenu de la variable. Ainsi, il est préférable d’utiliser la commande New-Variable ainsi que le paramètre -Option Constant, comme dans l’exemple ci-après :

PS > New-Variable -Name PI -Value 3.14 -Option Constant
 

De cette manière, nous sommes protégés du risque de modification du contenu. Pour nous en convaincre, essayons de voir ce qu’il se passe si nous essayons d’affecter une nouvelle valeur :

PS > $PI = 4 
 
Cannot overwrite variable PI because it is read-only or constant. 
At line:1 char:1 
+ $PI=4 
+ ~~~~~ 
    + CategoryInfo  : WriteError: (PI:String) [],  
SessionStateUnauthorized... 
    + FullyQualifiedErrorId : VariableNotWritable
 

Types de données

Bien qu’en général, dans les scripts de tous les jours, nous nous contentions des types de données les plus basiques qui soient, il est néanmoins possible d’en utiliser un très grand nombre. En effet, comme PowerShell tire toute sa puissance du framework .NET, tous les types .NET sont potentiellement accessibles et utilisables.

Pour le moment, nous nous contenterons de vous parler des types les plus communément utilisés.

Affectation manuelle de types et transtypage

Que les inconditionnels du « typage fort » se rassurent, il existe une alternative au typage automatique afin de rester maître du typage des variables. Pour ce faire, il nous faut définir le type souhaité entre crochets et placer ce dernier devant le nom de la variable, comme par exemple :

PS > [int]$var = 12
 

En écrivant cela, vous êtes sûr que la variable $var sera du type entier. Mais il n’y a aucune différence entre $var = 12 et [int]$var = 12, nous direz-vous ! Certes, pour l’instant l’intérêt est minime, mais lorsque vous serez de grands « powershelleurs » et que vos scripts commenceront à prendre de l’ampleur, le fait de déclarer vos variables avec un type associé rendra votre travail beaucoup plus compréhensible pour les autres mais permettra surtout d’éviter qu’une valeur d’un type différent ne lui soit affectée par erreur.

Exemple

PS > [int]$nombre = Read-Host 'Entrez un nombre '  
Entrez un nombre : cent 
 
Cannot convert value "cent" to type "System.Int32".  
Error: "Input string was not in a correct format."
 

Dans l’exemple ci-dessus, le texte saisi cent n’a pas été reconnu comme un nombre entier, il est donc...

Rendre obligatoires la déclaration et l’initialisation des variables

Une bonne pratique veut que l’on s’oblige à déclarer toutes nos variables dans un script, dans une fonction ou dans un bloc de script. En effet, à qui n’est-il jamais arrivé de chercher un bug dans un programme pendant des heures à cause d’une simple faute de frappe sur un nom de variable ?

Bien que ce comportement ne soit pas celui par défaut, il est possible d’imposer ce mode de fonctionnement grâce à l’utilisation de la commande Set-StrictMode.

Voici la syntaxe de cette commande :

PS > Get-Command Set-StrictMode -Syntax 
 
Set-StrictMode -Version <Version> [<CommonParameters>] 
Set-StrictMode -Off [<CommonParameters>]
 

Le paramètre -Version autorise les valeurs suivantes :

Variables prédéfinies

Portée des variables

La portée, appelée aussi « étendue » (scope en anglais), détermine la visibilité des variables (ou des fonctions). Dans cette partie, nous ne ferons qu’effleurer le sujet car il est très vaste et peut vite devenir complexe. Pour des explications plus détaillées, nous vous recommandons de consulter la rubrique d’aide About_Scopes.

La notion de portée est cependant importante, puisqu’elle garantit une indépendance des variables, ou du moins un mode de fonctionnement qu’il est utile de connaître afin d’éviter de probables interférences et autres effets indésirables.

Imaginez un instant que vous exécutiez un script et qu’une fois le script terminé vous souhaitiez vérifier une valeur en tapant son nom dans la console, aïe ! Ce n’est pas possible (par défaut, dans la console classique), car la variable n’est pas disponible ; ceci est tout simplement dû à la portée des variables.

PowerShell utilise la notion de portée parent et de portée enfant. Une portée enfant est une portée créée à l’intérieur d’une portée parent. C’est-à-dire qu’à chaque fois que nous exécutons une fonction, un script ou un bloc d’instructions, une nouvelle portée est créée. Et sauf spécification contraire de votre part, PowerShell définit qu’une variable peut être lue dans sa propre portée, ainsi que dans les portées enfants. Mais elle ne peut être modifiée que dans la portée où elle a été créée. De plus, les portées parentes ne peuvent ni lire ni modifier les variables définies dans leurs portées enfants. 

Le schéma ci-après...

Quantificateurs d’octets

L’une des caractéristiques de PowerShell est sa capacité à utiliser des quantificateurs d’octets. Ces derniers permettent de manipuler des multiples d’octets sans avoir à effectuer d’opération particulière. Les quantificateurs reconnus sont les suivants :

Historiquement, les scripteurs que nous sommes avons toujours contourné ces difficultés en faisant un peu de mathématiques : nous divisions un nombre d’octets par 1024, ce qui nous donnait des kilo-octets. On divisait ensuite par 1024 pour avoir des mégaoctets, etc. Mais il faut reconnaître que cela est bien plus pratique quand l’interpréteur de commandes gère cela nativement.

L’utilisation de ces quantificateurs est bien évidemment liée aux calculs de tailles, et cela est bien souvent le cas lorsqu’il s’agit de la capacité des disques ou de la mémoire, de la taille des fichiers ou des répertoires, etc.

Prenons pour exemple la requête CIM/WMI suivante qui retourne...