PowerShell Core : la version multi plate- forme du shell de Microsoft
La version multi plate- forme du shell de Microsoft
La version classique de PowerShell– c’est- àdire Windows – est disponible en natif depuis Windows 7/ Server 2008 R2. PowerShell Core 6.0 l’est officiellement depuis le 11 janvier dernier. Cette nouvelle version de PowerShell présente le double avantage d’être multi plate- forme ( Mac OS X, Windows et Linux) et open source, sous licence MIT.
Deux versions distinctes de PowerShell
Cette version ne s’appelle pas Core pour rien. Elle est open source et conçue pour les environnements hétérogènes ou hybrides. Contrairement à la version Windows pour les éditions clients et serveurs qui est basée sur le . NET Framework, PowerShell Core est, elle, fondée sur le . NET Core 2.0. C’est bien ce dernier qui fait toute la différence, car il est compatible avec de nombreux systèmes d’exploitation : Windows 7 au moins SP1, 8.1 et 10, au moins 1607, Windows Server 2008 R2 SP1, 2012 R2 et 2016, Ubuntu 14.04, 16.04 17.04 et 17.10, Debian 8.7 au minimum et 9, les « cousins » CentOS 7 et Red Hat Enterprise Linux 7, Fedora 25, 26 et 27, Linux Mint 17 et 18, OpenSUSE 42.2 et au- delà et Mac OS 10.12 et versions ultérieures. Cela ne veut pas dire pour autant que le support soit assuré par Microsoft pour toutes ces versions. C’est le cas notamment des plates- formes Kali Linux, Arch Linux, Raspbian, les systèmes AppImage et Windows sur architectures ARM32 et ARM64, non supportées officiellement. Il restera normalement compatible avec les versions supérieures de tous ces Operating Système. Le phénomène devrait aussi se propager à toutes les distributions Linux, la communauté, toujours éclairée n’ayant rien contre un shell multi plate- forme permettant l’exécution sur un parc de machines hétérogène de scripts écrits dans un seul et unique langage. Du moment que ce langage respecte les sacrosaints principes de l’Open Source, tout va pour le mieux dans le meilleur des mondes.
Installer PowerShell Core
Windows Power shel l et Powershell Core peuvent cohabiter sans problème sur une même machine Windows, ceci étant facilité par la différence entre les noms des
exécutables. PowerShell Core s’exécute à partir de la commande pwsh. exe alors que le lanceur de l’interpréteur Windows PowerShell est le programme powershell. exe. Chaque exe pwsh embarque son propre . Net Core – la version 2.0 à l’heure actuelle, se basant sur . Net standard. Du coup, il est aisé d’installer sur une même machine plusieurs versions distinctes en utilisant les versions portables. Cela permet entre autres choses d’installer PowerShell en local pour une application l’acceptant en tant que dépendance. Une installation côte à côte peut grandement faciliter le test de nouvelles versions de PowerShell ainsi que la migration de scripts existants au fil du temps. Cela a aussi pour effet d’améliorer la rétrocompatibilité, les scripts pouvant ainsi être associés aux versions spécifiques dont ils ont besoin.
Le programme pwsh
D’autres modifications ont été apportées à pwsh par rapport à powershell. exe. Le premier paramètre positionnel - Command a été remplacé par - File. Cette modification résout l’utilisation du shebang ( la séquence #! suivie du langage de script à employer, positionnée en toute première ligne dans les scripts . sh POSIX) dans les scripts PowerShell exécutés depuis un autre shell que PowerShell sur des plates- formes Unix/ Linux ( bash, ksh, zsh…). Cela signifie également que vous pouvez exécuter des commandes telles que pwsh fichier. ps1 ou pwsh fichier sans forcément spécifier l’option - File. D’un autre côté, cette modification nécessite la spécification explicite de - c ou - Command pour exécuter des commandes telles que pwsh. exe - Command Get- Command. PowerShell Core accepte le commutateur - i ( ou - Interactive) pour lancer un shell interactif. PowerShell peut ainsi être utilisé comme shell par défaut sur les plates- formes POSIX. Les messages d’erreur d’arguments non valides pour les paramètres - File et - Command et les codes de sortie sont désormais conformes aux normes Unix/ Linux.
Modifications apportées à la version Core
Un certain nombre de modifications ont été apportées à PowerShell Core 6 pour qu’il fonctionne mieux sur les systèmes autres que Windows.
Certaines de ces modifications affectent également Windows. D’autres sont uniquement présentes ou applicables dans des installat ions non- Windows de PowerShell Core. En voici quelques- unes parmi les principales : • ajout de la prise en charge du globbing des commandes natives sur les plates- formes Unix ; • la barre oblique inverse de fin est automatiquement placée dans une séquence d’échappement quand vous traitez des arguments de commande native ; • le commutateur - ExecutionPolicy est ignoré lors de l’exécution de PowerShell sur les plates- formes non- Windows, la signature de script n’y étant pas encore prise en charge ; • ConsoleHost a été corrigé afin d’assurer le fonctionnement de NoEcho sur les plateformes Unix ; • la commande Get- Help a elle aussi été modifiée pour prendre en charge les critères spéciaux ne respectant par la casse sur les plateformes Unix ; • une page man powershell a été ajoutée au package.
Journalisation
La journalisation étant fortement dépendante du système d’exploitation, Microsoft a bien dû s’adapter. Sous Mac OS, PowerShell utilise les API os_ log natives pour se connecter au système de journalisation unifiée d’Apple. Sous Linux, c’est la solution de journalisation syslog, très répandue, qui est employée.
FileSystem
Plusieurs modifications ont été apportées aux versions Mac OS et Linux en vue de prendre en charge les caractères de nom de fichier généralement non pris en charge sur Windows. Cela concerne la spécification des chemins ( path) par les applets de commande. Les chemins sont désormais indépendants des barres obliques (/ et \). Le slash et l’antislash sont tous deux disponibles comme séparateurs de répertoires. La spécification de répertoire de base XDG est désormais respectée et même utilisée par défaut. Cela se traduit par plusieurs choses : • le chemin du profil Linux/ MacOS se trouve dans ~/. config/ powershell/ profile. ps1 • l’historique Powershell est enregistré dans le fichier ~/. local/ share/ powershell/ PSReadline/ ConsoleHost_ history. txt • le répertoire des modules utilisateur est ~/. local/ share/ powershell/ Modules Les noms de fichier et de dossier contenant le caractère deuxpoints (:) sont pris en charge sous Unix/ Linux. Les noms de fichiers de script et des chemins complets contenant des virgules sont eux aussi pris en charge. Le paramètre - LiteralPath permet de supprimer le développement des caractères génériques pour les applets de commande de navigation ( Set- location, notamment). La commande Get- ChildItem – l’équivalent ou presque en PowerShell de ls sous Posix ou dir sous Windows – a été mise à jour en vue de fonctionner de manière plus normalisée avec des appels de type commandes natives POSIX ( comme les - R) et Windows ( dir / S). GetChildItem retourne désormais les liens symboliques rencontrés lors d’une recherche récursive et a même été enrichie d’un paramètre (- FollowSymlink) lui permettant de les traverser à la demande. L’utilisation du fournisseur Filesystem peut être activée à partir d’un chemin UNC. Le cd sans argument se comporte maintenant comme cd ~ et, point non négligeable, PowerShell Core autorise l’utilisation de chemins d’une longueur de plus de 260 caractères.
Rétrocompatibilité avec Windows PowerShell
L’objectif de Microsoft est de faire en sorte que PowerShell Core reste aussi compatible que possible avec Windows PowerShell. PowerShell Core s’appuie pour cela sur le . NET Standard 2.0 pour assurer la compatibilité binaire avec des assemblys . NET existants. Un grand nombre de modules PowerShell
dépendant de ces assemblys, le . NET Standard permet à . NET Core de les utiliser. PowerShell Core inclut également une méthode heuristique d’examen des dossiers connus tel que celui où se trouve généralement le Global Assembly Cache sur le disque et de recherche des dépendances des dll du . NET Framework. Microsoft a, semble- t- il, tout mis en oeuvre afin de garantir que le langage PowerShell et les modules intégrés tels que Microsoft. PowerShell. Management, Microsoft. PowerShell. Utility ou autres fonctionnent de la même manière que dans Windows PowerShell. Dans quelques cas de figure, et ce en raison d’une dépendance manquante dans les couches . NET sous- jacentes, la fonctionnalité a été supprimée. La plupart des modules « purs » Windows ( DnsClient, Hyper- V, NetTCPIP, Storage…) et ceux des autres produits Microsoft comme Azure ou Office n’ont pas encore été explicitement déplacés vers. NET Core. L’équipe PowerShell y travaille, avec les équipes des logiciels concernés pour valider et déplacer leurs modules existants vers PowerShell Core. Grace à. NET Standard et CDXML, la plupart de ces modules fonctionnent dans PowerShell Core, mais ils ne sont ni validés ni pris en charge d’un point de vue officiel. Si vous souhaitez utiliser des modules Windows PowerShell dans PowerShell Core, installez le module WindowsPSModulePath et ajoutez le Windows PowerShell PSModulePath à PowerShell Core PSModulePath. Voici comment procéder, après avoir téléchargé WindowsPSModulePath depuis la PowerShell Gallery : # Ajoutez le paramètre - Scope CurrentUser si vous n’êtes pas administrateur Install- Module WindowsPSModulePath - Force Exécutez l’applet de commande Add- WindowsPSModulePath qui ajoutera directement Windows PowerShell PSModulePath à PowerShell Core : Add- WindowsPSModulePath Pour que cela soit systématique, ajoutez la ligne précédente à un fichier de profil PowerShell.
Les modules compatibles avec les deux versions
Certains modules sont intégrés nativement à Powershell Core. En voici la liste donnée par Microsoft : CimCmdlets, Microsoft. PowerShell. Archive, Microsoft. PowerShell. Dia gnos t i c s , Micro s of t . PowerShell. Host, Microsoft. PowerShell. Management, Microsoft. PowerShell. Security, Microsoft. PowerShell. Utility, Microsoft. WSMan. Management, PackageManagement, PowerShellGet, PSDesiredStateConfiguration, PSDiagnostics et PSReadLine. Il n’y a, pour le moment, aucune garantie quant au parfait fonctionnement des modules first- party de Microsoft avec PowerShell Core. Les modules concernés sont ceux intégrés à Windows ( parties client et serveur), les modules intégrés à des produits Microsoft tels que Exchange ou SharePoint ou encore les modules de la PowerShell Gallery ( https:// www. powershellgallery. com/). Concrètement, la plupart des commandes et donc des scripts écrits en Windows PowerShell ( toutes versions) fonctionnent, mais vous pouvez rencontrer des problèmes de temps en temps avec certaines instructions ou paramètres. Cela devrait se résoudre progressivement grâce à l’action conjuguée de Microsoft et de la communauté PowerShell. Les API partagées entre . NET Core et le . NET Framework sont définies dans le cadre de . NET Standard ( cf https:// docs. microsoft. com/ fr- fr/ dotnet/ standard/ net- standard).
Respect de la casse
Linux et Mac OS X ont tendance à respecter la casse, ce qui n’est pas vraiment le cas de Windows.
En règle générale, PowerShell ne respecte pas la casse, sauf cas particulier et en le spécifiant ( en ajoutant c devant les opérateurs, par exemple : - cmatch au lieu de - match, - clike au lieu de - like, etc). Comme les variables d’environnement respectent forcément la casse sous Mac OS X et Linux, la casse de la variable d’environnement PSModulePath a été normalisée. La cmdlet Import- Module, en revanche, ne respecte pas la casse lorsque vous spécifiez le nom d’un module à charger.
Prise en charge de Docker
PowerShell Core ajoute la prise en charge des conteneurs Docker pour les principales platesformes, ceci incluant plusieurs distributions Linux, Windows Server Core et Nano Server. La liste exhaustive est disponible à l’adresse https:// hub. docker. com/ r/ microsoft/ powershell/. Vous trouverez plus d’informations sur Docker et PowerShell Core à l’adresse https:// github. com/ PowerShell/ PowerShell/ tree/ master/ docker.
Encodage par défaut en UTF- 8
Jusque- là, les applets de commande Windows PowerShell telles que Get- Content ou Set- Content utilisaient des encodages différents comme ASCII et UTF- 16. Cela générait, du coup, des problèmes lorsque l’on associait ( via le pipe) des applets de commande sans préciser l’encodage à employer. Les plates- formes POSIX utilisent en général l’encodage UTF- 8 sans marque d’ordre d’octet comme encodage par défaut pour les fichiers texte. D’autres outils et applications Windows passent de l’encodage UTF- 16 à l’encodage UTF- 8 sans marque d’ordre d’octet. PowerShell Core modifie donc l’encodage par défaut afin de se conformer à la majorité des distributions POSIX. Plus concrètement, toutes les applets de commande intégrées employant le paramètre - Encoding utilisent la valeur par défaut UTF8NoBOM. Les applets de commande affectées par cette modification sont Add- Content, Export- Clixml, Export- Csv, Export- PSSession, FormatHex, Get- Content, Impor tCsv, New- ModuleManifest, Out- File, Select- String, SendMailMessage et Set- Content. Ces commandlets ont également été mises à jour afin que le paramètre - Encoding accepte universellement System. Text. Encoding. La valeur par défaut de la variable de préférence $ OutputEncoding a elle aussi été remplacée par UTF- 8.
Cycle de vie et support de PowerShell Core
PowerShell Core est publié sous licence MIT. Cela veut dire qu’en l’absence d’un contrat de support payant, les utilisateurs ne peuvent bénéficier que du support de la communauté, sans aucune garantie de réactivité ou de livraison de correctif de la part de l’éditeur. Bien que le support de PowerShell Core ne soit pas inclus par défaut dans les contrats de licence Windows et Windows Server, il est néanmoins pris en charge dans des contrats de support Microsoft classiques tels que Premier, les contrats Entreprise Microsoft et la Microsoft Software Assurance. Il est aussi envisageable de payer pour obtenir un support spécifique pour PowerShell Core. Vous disposez d’un support de la communauté sur GitHub, où vous pouvez signaler un problème, un bogue ou une demande de nouvelle fonctionnalité. Aucune garantie n’est assurée quant à la prise en compte du dit problème. PowerShell Core adopte la politique de support moderne Microsoft ( similaire à celle de Windows 10). Cette politique de support est destinée à maintenir les clients à jour avec les dernières versions. La branche PowerShell Core version 6. x sera mise à jour environ une fois tous les six mois. Vous devrez en revanche effectuer la mise à jour de PowerShell Core dans les six mois suivant la publication de chaque nouvelle version mineure afin de pouvoir continuer à profiter du support de version. Cela implique également que Microsoft prévienne ses clients 12 mois avant la fin du support d’un produit. Au final, PowerShell Core devrait suivre l’approche de maintenance à long terme ( LTSB pour Long Term Servicing Branch) où seules la maintenance et les mises à jour de sécurité resteront en support sur une branche/ version spécifique de 6. x. ❍