Blog ENI : Toute la veille numérique !
Accès illimité 24h/24 à tous nos livres & vidéos ! 
Découvrez la Bibliothèque Numérique ENI. Cliquez ici
Accès illimité 24h/24 à tous nos livres & vidéos ! 
Découvrez la Bibliothèque Numérique ENI. Cliquez ici
  1. Livres et vidéos
  2. PowerShell Core et Windows PowerShell
  3. À la découverte de PowerShell
Extrait - PowerShell Core et Windows PowerShell Les fondamentaux du langage (2e édition)
Extraits du livre
PowerShell Core et Windows PowerShell Les fondamentaux du langage (2e édition)
4 avis
Revenir à la page d'achat du livre

À la découverte de PowerShell

Présentation de PowerShell

PowerShell est à la fois un interpréteur de commandes et un puissant langage de scripts. Il tire sa puissance en grande partie grâce au Framework .NET sur lequel il s’appuie. Bien connu des développeurs, le Framework .NET l’est en revanche beaucoup moins des administrateurs système et autres développeurs de scripts ; ce qui est normal... Pour vulgariser en quelques mots, le Framework .NET est une immense bibliothèque de classes à partir desquelles nous ferons naître des objets ; objets qui nous permettront d’agir sur l’ensemble du système d’exploitation en un minimum d’effort. Tous ceux qui ont goûté à la puissance du Framework .NET ne tariront pas d’éloges à son égard. C’est donc grâce à ce dernier que PowerShell tire toute son intelligence ainsi que sa dimension objet. Et c’est d’ailleurs cette faculté à manipuler les objets qui fait de PowerShell un shell d’exception !

Avec PowerShell vous ne manipulerez donc plus uniquement du texte, comme c’est le cas avec la plupart des autres shells, mais des objets ; et ce, sans vraiment vous en rendre compte. Par exemple, lorsque vous utiliserez le pipe « | » pour passer des données à une commande, eh bien vous ne transmettrez...

Historique des versions

C’est dans les années 2003-2004 que la firme de Redmond comprit qu’il lui manquait un véritable langage de scripts homogène mais surtout qu’il était temps que tous les produits de la gamme System Center puissent être administrables entièrement en lignes de commandes.

C’est ainsi que le projet Monad vit le jour, projet qui donna naissance fin 2006 à la première version de PowerShell. Jusqu’à la version 3, le rythme de sortie des versions se faisait tous les trois ans, ce qui correspondait à celui des versions de Windows. Depuis 2012, le rythme s’est nettement accéléré et le cycle a été réduit de moitié, soit une nouvelle version tous les dix-huit mois. Ce rythme soutenu n’est pas un hasard ; il est le fruit de l’adoption de la démarche Agile au sein de Microsoft qui consiste à sortir des produits plus souvent mais avec moins de nouvelles fonctionnalités. Cette démarche s’oppose à celle utilisée jusqu’alors qui consistait à sortir une nouvelle version majeure contenant de nombreuses évolutions mais à un rythme nettement plus lent. Ce nouveau paradigme s’inscrit en plein dans la démarche DevOps dont nous aurons l’occasion de reparler plus longuement… Monad

images/EI01-01.png

Historique de sortie des versions

2016 est une date clé dans le petit monde PowerShell car cette année vit apparaître la première version de PowerShell, appelée « PowerShell Core ». Celui-ci s’appuie désormais non plus sur le Framework .NET mais sur .NET Core (nous aurons l’occasion de reparler plus longuement dans le chapitre Framework .NET et .NET Core). Net Core est la déclinaison open source du Framework .NET. PowerShell Core sort donc officiellement en version 5.1 et il fait partie de Windows Server Nano appelé également « Nano Server ». En parallèle de cela, quelques mois auparavant, Microsoft publiait sur Github.com le code source de PowerShell et le libérait sous licence MIT. PowerShell devint alors officiellement open source et multiplateformes grâce à la portabilité intrinsèque de .NET Core, lui-même également multiplateformes.

La sortie de Windows Server 2016 est une date importante dans l’éco-système PowerShell car elle est aussi synonyme de rupture. En effet, on se trouve désormais avec deux versions distinctes de PowerShell que sont « Windows PowerShell 5.1 » et « PowerShell...

Plateformes supportées

1. Plateformes clientes

Versions supportées

Windows 7 SP1

Windows 8.1

Windows 10

V3 / Framework .NET 4.0

À installer

V4 / Framework .NET 4.5

À installer

Natif

V5.1 / Framework .NET 4.5.2

À installer

À installer

Natif

V6.0 (Core) / .NET Core 2.0

À installer

À installer

À installer

Les cases vides signifient que la configuration n’est pas supportée. La mention « À installer » signifie qu’il est possible d’installer PowerShell (dans la version précisée sur la ligne correspondante) sur cette plateforme. « Natif » indique que PowerShell est installée de manière native.

À noter que Windows PowerShell 2.0 n’est plus supporté par Microsoft depuis août 2017.

2. Plateformes serveur

Versions supportées

Windows Server 2008 R2

Windows Server 2012/R2

Windows Server 2016

Mac OS

Linux

V3 / Framework .NET 4.0

À installer

V4 / Framework .NET 4.5

À installer

Natif

V5.1 / Framework .NET 4.5.2

À installer

À installer

Natif

V6.0 (Core) / .NET Core 2.0

À installer

À installer

À installer

À installer

À installer

Avant d’utiliser PowerShell sur les versions citées ci-dessus, il vous faudra vous acquitter de deux opérations. La première, impérative, est de vérifier la version...

Prise en main

En plus de la console en ligne de commande, il existe depuis la version 2.0 un appréciable environnement de développement de scripts PowerShell en mode graphique appelé PowerShell ISE. L’avantage de ce dernier est qu’il est installé de base sur toutes les versions de Windows. Son « inconvénient » est qu’il ne prend en charge que Windows PowerShell. Par conséquent, il laisse de côté PowerShell Core.

C’est la raison pour laquelle, depuis peu, Microsoft met en avant un nouvel environnement de développement multiplateforme appelé Visual Studio Code. Ce dernier est polyvalent car il prend en charge toutes les éditions de PowerShell et il est disponible sur toutes les plateformes (Windows, Mac, Linux).

Dans un premier temps, nous nous intéresserons à la console « classique », console que nous pourrions qualifier d’« historique » du fait qu’elle existe depuis la toute première version.

1. Console Windows PowerShell classique

a. Démarrage de la console

Lorsque l’on démarre la console PowerShell, il faut savoir que cette dernière s’exécute avec des droits de simple utilisateur et donc limités ; et ce, même si l’on a ouvert notre session avec un compte administrateur. Ne soyez donc pas surpris si vous vous voyez l’accès refusé à certains répertoires, à certaines clés de registre ou à certaines commandes. Ceci est dû au mécanisme de sécurité bien connu nommé « User Account Control » (UAC) pour « contrôle de comptes d’utilisateurs » en français.

Pour ouvrir une console classique ou graphique (ISE) avec le privilège Administrateur, vous devez systématiquement effectuer un clic droit sur l’icône PowerShell (ou PowerShell ISE) et choisir Exécuter en tant qu’administrateur (ou Run as Administrator sur un système en anglais) comme ci-après.

images/EIN01-RunAs.PNG

Exécuter en tant qu’administrateur - Menu contextuel

Vous ferez la différence entre les consoles PowerShell ouvertes en tant qu’administrateur et celles qui ne le sont pas en observant l’intitulé des fenêtres en haut à gauche...

Une transition en douceur avec le passé

Les scripts sont rétrocompatibles, c’est-à-dire que, par exemple, les scripts écrits pour la version 1 de PowerShell fonctionneront avec la version 5.x. Du moins, en principe… car chaque nouvelle version apporte potentiellement de nouveaux mots-clés, commandes et variables et donc si par malchance vous les avez employés en tant que noms de variable ou de fonction, vous pourriez alors rencontrer quelques dysfonctionnements… Mais ne vous affolez pas pour autant car, dans plus de 99 % des cas, il n’y a pas de problème, ou alors c’est que vous n’avez pas de chance...

Il convient cependant de nuancer un peu nos propos car depuis PowerShell 6, les choses ont quelque peu changé. En effet, comme nous vous le disions au début de ce chapitre, PowerShell 6 représente en quelque sorte un renouveau dans l’écosystème PowerShell du fait qu’il soit maintenant open source et multiplateforme. Microsoft s’est donc autorisé de nombreux « breaking changes », entendez par là des changements pouvant entraîner des dysfonctionnements sur des scripts existants.

Quant aux inconditionnels de CMD qui ne se seraient pas encore convertis à PowerShell, qu’ils se rassurent : PowerShell ne fait pas table rase du passé. Pratiquement toutes les commandes qui étaient...

Système d’aide intégré

Depuis PowerShell 3.0 la philosophie de Microsoft vis-à-vis du système d’aide intégré a profondément changé. Dans les versions précédentes, l’aide était installée en standard et celle-ci était disponible en français. Ce n’est désormais plus le cas depuis la version 3...

Ainsi pour pouvoir bénéficier du système d’aide, très complet par ailleurs (mais exclusivement en anglais à présent), il faut télécharger l’aide. Bien que cela puisse sembler contraignant au premier abord, cela nous garantit de disposer des derniers fichiers d’aide disponibles. En effet, l’aide est régulièrement actualisée par Microsoft et il est possible de bénéficier des mises à jour, chose qui n’était pas possible auparavant. Seul petit inconvénient, il faut que la machine sur laquelle on télécharge l’aide ait un accès direct à Internet, c’est-à-dire sans passer par un proxy, ou qu’un administrateur ait au préalable téléchargé l’aide et l’ait placée sur un partage réseau. De plus, vous devez être administrateur de votre ordinateur pour pouvoir mettre à jour l’aide.Mais ne vous en faites pas trop car PowerShell propose toutes les commandes pour mettre à disposition les fichiers d’aide en environnement d’entreprise.

Si l’aide n’est pas installée sur votre système, vous vous en rendrez compte rapidement car seule l’aide syntaxique est proposée. Autrement dit, vous n’aurez accès qu’à la découverte du nom des paramètres sans plus d’explications.

Exemple

Demande d’aide sur une commande lorsque l’aide n’est pas installée.


PS > help update-help 
 
NAME 
    Update-Help 
 
SYNTAX 
    Update-Help [[-Module] <string[]>] [[-SourcePath] <string[]>] 
[[-UICultur... ...

Commandes de base

Avant toute chose, PowerShell est un environnement en lignes de commandes au service du système d’exploitation mais aussi et surtout au service des utilisateurs. En tant que tel, il est livré avec un jeu de commandes qu’il est bon de connaître, ou tout du moins de savoir comment les trouver ou les retrouver lorsque l’on a la mémoire courte…

1. Constitution des commandes

Les commandes PowerShell sont appelées cmdlets (pour command-applets). Pour notre part, comme il n’existe pas de traduction officielle, nous avons pris le parti de les nommer commandelettes. Ceci étant dit, la plupart du temps, nous les appellerons plus simplement des commandes. Elles sont constituées de la manière suivante : un verbe suivi d’un nom séparé par un tiret (-) : verbe-nom. Par exemple, Get-Command.

Le verbe (en anglais bien sûr) décrit l’action à appliquer sur le nom. Dans cet exemple on récupère (Get) les commandes (Command).

Avec PowerShell on trouve de nombreux verbes génériques tels que Get, Set, Add, Remove, etc. qui se combinent avec différents noms comme Path, Variable, Item, Object, Computer, etc.

Les noms constituant les commandes sont toujours au singulier ; et ceci vaut également pour les paramètres.

On peut donc, en croisant les verbes et les noms, se souvenir facilement de bon nombre de commandes. Notez que les commandes, ainsi que leurs paramètres associés, peuvent s’écrire indifféremment en majuscules ou en minuscules, l’analyseur de syntaxe PowerShell n’étant absolument pas sensible à la casse (sauf dans le cas de PowerShell 6 sous Mac OS ou Linux).

Retrouvez la liste complète des verbes officiels et leurs groupes d’applications en utilisant la commande Get-Verb.

Il est d’usage, et il s’agit aussi d’une bonne pratique, de toujours choisir un verbe approuvé lorsque l’on crée des fonctions ou des scripts à destination d’autres utilisateurs, et ce dans le but de préserver une certaine homogénéité globale entre vos propres commandes et celles de Microsoft.

2. Get-Command

Si vous ne deviez n’en retenir qu’une seule, alors retenez au moins celle-là : Get-Command. Cette commande permet...

Gestion des répertoires et des fichiers

Nous avons vu que nous pouvions utiliser les bonnes vieilles commandes DOS/CMD afin de nous déplacer dans une hiérarchie de dossiers. Bien que cela soit toujours possible et fasse gagner du temps à celui qui les emploie, cela ne lui élève pas son niveau de connaissance de PowerShell.

Lorsque vous tapez DIR en PowerShell, vous faites en réalité appel à un alias. L’alias vous fait exécuter la commande Get-ChildItem. Pour le vérifier, tapez la commande suivante :


PS > Get-Alias dir 
 
CommandType     Name                     ModuleName 
-----------     ----                     ---------- 
Alias           dir -> Get-ChildItem
 

Voici un tableau récapitulatif des principales commandes CMD et de leurs équivalents en PowerShell.

DOS/CMD

Équivalent PowerShell (alias)

Commandelette PowerShell

Description

dir

dir, gci, ls

Get-ChildItem

Liste le contenu d’un répertoire.

cd

cd, chdir, sl

Set-Location

Change de répertoire courant.

md

md, ni

New-Item

Crée un fichier/répertoire.

rd

del, erase, rd, ri, rm, rmdir

Remove-Item

Supprime un fichier/répertoire.

move

mi, move, mv

Move-Item

Déplace un fichier/répertoire.

ren

ren, rni

Rename-Item

Renomme un fichier/répertoire.

copy

copy, cp, cpi

Copy-Item

Copie un fichier/répertoire.

Comme l’objet de cet ouvrage est l’apprentissage de PowerShell, nous nous efforcerons de ne plus utiliser les anciennes commandes CMD, et nous vous encourageons à faire de même !

On peut s’apercevoir qu’il existe de nombreux alias empruntés au monde Unix, tels que ls, rm, cp. Ceux-ci ont été créés pour faciliter l’accès à PowerShell pour les personnes venant de ces environnements. À noter que ces alias n’existent que dans PowerShell sous Windows. En effet, ils ont été supprimés dans PowerShell 6 sur et uniquement sur les plateformes Mac OS et Linux afin de laisser la possibilité d’appeler les véritables commandes natives.

1. Get-ChildItem (alias : gci, ls, dir)

Cette commande permet d’obtenir les fichiers et dossiers présents...

Fournisseurs PowerShell

Maintenant que vous êtes familier avec le jeu de commandes qui permet de naviguer et de gérer une arborescence de fichiers et de dossiers, nous pouvons vous avouer que celui-ci permet également bien d’autres choses…

Toutes les commandes que nous avons vues précédemment (familles *-Item et *-Location) permettent la manipulation non seulement du système de fichiers mais aussi :

  • de la base de registre,

  • des variables,

  • des variables d’environnement,

  • des alias,

  • de la base de certificats X.509 de votre ordinateur,

  • des fonctions,

  • et du paramétrage WSMan (utile à la fonctionnalité Remote PowerShell).

Un certificat X.509 permet de signer et/ou de chiffrer des données.

C’est ce qui explique la généricité du nom des commandes *-Item, dans la mesure ou un « item » peut représenter par exemple un fichier, un dossier, une clé de registre, une variable ou tout autre chose.

Toutes les sources de données que nous venons d’énumérer précédemment sont accessibles par le biais de ce que l’on appelle dans le jargon PowerShell des fournisseurs (on rencontre également très couramment les termes Provider ou PSProvider). Ils sont au nombre de huit mais seuls six sont affichés par défaut. Afin d’en obtenir la liste et les détails associés, tapez la commande Get-PSProvider.


PS > Get-PSProvider 
 
Name        Capabilities                       Drives 
----        ------------                       ------ 
Alias       ShouldProcess                      {Alias} 
Environment ShouldProcess                      {Env} 
FileSystem  Filter, ShouldProcess, Credentials {C, E, D, F} 
Function    ShouldProcess            ...