Po­werS­hell Core : la ver­sion mul­ti plate- forme du shell de Mi­cro­soft

La ver­sion mul­ti plate- forme du shell de Mi­cro­soft

L'Informaticien - - SOMMAIRE - THIER­RY THAUREAUX

La ver­sion clas­sique de Po­werS­hell– c’est- àdire Win­dows – est dis­po­nible en na­tif de­puis Win­dows 7/ Ser­ver 2008 R2. Po­werS­hell Core 6.0 l’est of­fi­ciel­le­ment de­puis le 11 jan­vier der­nier. Cette nou­velle ver­sion de Po­werS­hell pré­sente le double avan­tage d’être mul­ti plate- forme ( Mac OS X, Win­dows et Li­nux) et open source, sous li­cence MIT.

Deux ver­sions dis­tinctes de Po­werS­hell

Cette ver­sion ne s’ap­pelle pas Core pour rien. Elle est open source et con­çue pour les en­vi­ron­ne­ments hé­té­ro­gènes ou hy­brides. Con­trai­re­ment à la ver­sion Win­dows pour les édi­tions clients et ser­veurs qui est ba­sée sur le . NET Fra­me­work, Po­werS­hell Core est, elle, fon­dée sur le . NET Core 2.0. C’est bien ce der­nier qui fait toute la dif­fé­rence, car il est com­pa­tible avec de nom­breux sys­tèmes d’ex­ploi­ta­tion : Win­dows 7 au moins SP1, 8.1 et 10, au moins 1607, Win­dows Ser­ver 2008 R2 SP1, 2012 R2 et 2016, Ubun­tu 14.04, 16.04 17.04 et 17.10, De­bian 8.7 au mi­ni­mum et 9, les « cou­sins » CentOS 7 et Red Hat En­ter­prise Li­nux 7, Fe­do­ra 25, 26 et 27, Li­nux Mint 17 et 18, OpenSUSE 42.2 et au- de­là et Mac OS 10.12 et ver­sions ul­té­rieures. Ce­la ne veut pas dire pour au­tant que le sup­port soit as­su­ré par Mi­cro­soft pour toutes ces ver­sions. C’est le cas no­tam­ment des plates- formes Ka­li Li­nux, Arch Li­nux, Rasp­bian, les sys­tèmes AppI­mage et Win­dows sur ar­chi­tec­tures ARM32 et ARM64, non sup­por­tées of­fi­ciel­le­ment. Il res­te­ra nor­ma­le­ment com­pa­tible avec les ver­sions su­pé­rieures de tous ces Ope­ra­ting Sys­tème. Le phé­no­mène de­vrait aus­si se pro­pa­ger à toutes les dis­tri­bu­tions Li­nux, la com­mu­nau­té, tou­jours éclai­rée n’ayant rien contre un shell mul­ti plate- forme per­met­tant l’exé­cu­tion sur un parc de ma­chines hé­té­ro­gène de scripts écrits dans un seul et unique lan­gage. Du mo­ment que ce lan­gage res­pecte les sa­cro­saints prin­cipes de l’Open Source, tout va pour le mieux dans le meilleur des mondes.

Ins­tal­ler Po­werS­hell Core

Win­dows Po­wer shel l et Po­wers­hell Core peuvent co­ha­bi­ter sans pro­blème sur une même ma­chine Win­dows, ce­ci étant fa­ci­li­té par la dif­fé­rence entre les noms des

exé­cu­tables. Po­werS­hell Core s’exé­cute à par­tir de la com­mande pwsh. exe alors que le lan­ceur de l’in­ter­pré­teur Win­dows Po­werS­hell est le pro­gramme po­wers­hell. exe. Chaque exe pwsh em­barque son propre . Net Core – la ver­sion 2.0 à l’heure ac­tuelle, se ba­sant sur . Net stan­dard. Du coup, il est ai­sé d’ins­tal­ler sur une même ma­chine plu­sieurs ver­sions dis­tinctes en uti­li­sant les ver­sions por­tables. Ce­la per­met entre autres choses d’ins­tal­ler Po­werS­hell en lo­cal pour une ap­pli­ca­tion l’ac­cep­tant en tant que dé­pen­dance. Une ins­tal­la­tion côte à côte peut gran­de­ment fa­ci­li­ter le test de nou­velles ver­sions de Po­werS­hell ain­si que la mi­gra­tion de scripts exis­tants au fil du temps. Ce­la a aus­si pour ef­fet d’amé­lio­rer la ré­tro­com­pa­ti­bi­li­té, les scripts pou­vant ain­si être as­so­ciés aux ver­sions spé­ci­fiques dont ils ont be­soin.

Le pro­gramme pwsh

D’autres mo­di­fi­ca­tions ont été ap­por­tées à pwsh par rap­port à po­wers­hell. exe. Le pre­mier pa­ra­mètre po­si­tion­nel - Com­mand a été rem­pla­cé par - File. Cette mo­di­fi­ca­tion ré­sout l’uti­li­sa­tion du she­bang ( la sé­quence #! sui­vie du lan­gage de script à em­ployer, po­si­tion­née en toute pre­mière ligne dans les scripts . sh POSIX) dans les scripts Po­werS­hell exé­cu­tés de­puis un autre shell que Po­werS­hell sur des plates- formes Unix/ Li­nux ( bash, ksh, zsh…). Ce­la si­gni­fie éga­le­ment que vous pou­vez exé­cu­ter des com­mandes telles que pwsh fi­chier. ps1 ou pwsh fi­chier sans for­cé­ment spé­ci­fier l’op­tion - File. D’un autre cô­té, cette mo­di­fi­ca­tion né­ces­site la spé­ci­fi­ca­tion ex­pli­cite de - c ou - Com­mand pour exé­cu­ter des com­mandes telles que pwsh. exe - Com­mand Get- Com­mand. Po­werS­hell Core ac­cepte le com­mu­ta­teur - i ( ou - In­ter­ac­tive) pour lan­cer un shell in­ter­ac­tif. Po­werS­hell peut ain­si être uti­li­sé comme shell par dé­faut sur les plates- formes POSIX. Les mes­sages d’er­reur d’ar­gu­ments non va­lides pour les pa­ra­mètres - File et - Com­mand et les codes de sor­tie sont dé­sor­mais conformes aux normes Unix/ Li­nux.

Mo­di­fi­ca­tions ap­por­tées à la ver­sion Core

Un cer­tain nombre de mo­di­fi­ca­tions ont été ap­por­tées à Po­werS­hell Core 6 pour qu’il fonc­tionne mieux sur les sys­tèmes autres que Win­dows.

Cer­taines de ces mo­di­fi­ca­tions af­fectent éga­le­ment Win­dows. D’autres sont uni­que­ment pré­sentes ou ap­pli­cables dans des ins­tal­lat ions non- Win­dows de Po­werS­hell Core. En voi­ci quelques- unes par­mi les prin­ci­pales : • ajout de la prise en charge du glob­bing des com­mandes na­tives sur les plates- formes Unix ; • la barre oblique in­verse de fin est au­to­ma­ti­que­ment pla­cée dans une sé­quence d’échap­pe­ment quand vous trai­tez des ar­gu­ments de com­mande na­tive ; • le com­mu­ta­teur - Exe­cu­tionPo­li­cy est igno­ré lors de l’exé­cu­tion de Po­werS­hell sur les plates- formes non- Win­dows, la si­gna­ture de script n’y étant pas en­core prise en charge ; • Con­so­leHost a été cor­ri­gé afin d’as­su­rer le fonc­tion­ne­ment de NoE­cho sur les pla­te­formes Unix ; • la com­mande Get- Help a elle aus­si été mo­di­fiée pour prendre en charge les cri­tères spé­ciaux ne res­pec­tant par la casse sur les pla­te­formes Unix ; • une page man po­wers­hell a été ajou­tée au pa­ckage.

Jour­na­li­sa­tion

La jour­na­li­sa­tion étant for­te­ment dé­pen­dante du sys­tème d’ex­ploi­ta­tion, Mi­cro­soft a bien dû s’adap­ter. Sous Mac OS, Po­werS­hell uti­lise les API os_ log na­tives pour se connec­ter au sys­tème de jour­na­li­sa­tion uni­fiée d’Apple. Sous Li­nux, c’est la so­lu­tion de jour­na­li­sa­tion sys­log, très ré­pan­due, qui est em­ployée.

Fi­leSys­tem

Plu­sieurs mo­di­fi­ca­tions ont été ap­por­tées aux ver­sions Mac OS et Li­nux en vue de prendre en charge les ca­rac­tères de nom de fi­chier gé­né­ra­le­ment non pris en charge sur Win­dows. Ce­la concerne la spé­ci­fi­ca­tion des che­mins ( path) par les ap­plets de com­mande. Les che­mins sont dé­sor­mais in­dé­pen­dants des barres obliques (/ et \). Le slash et l’an­ti­slash sont tous deux dis­po­nibles comme sé­pa­ra­teurs de ré­per­toires. La spé­ci­fi­ca­tion de ré­per­toire de base XDG est dé­sor­mais res­pec­tée et même uti­li­sée par dé­faut. Ce­la se tra­duit par plu­sieurs choses : • le che­min du pro­fil Li­nux/ MacOS se trouve dans ~/. config/ po­wers­hell/ pro­file. ps1 • l’his­to­rique Po­wers­hell est en­re­gis­tré dans le fi­chier ~/. lo­cal/ share/ po­wers­hell/ PSRead­line/ Con­so­leHost_ his­to­ry. txt • le ré­per­toire des mo­dules uti­li­sa­teur est ~/. lo­cal/ share/ po­wers­hell/ Mo­dules Les noms de fi­chier et de dos­sier conte­nant le ca­rac­tère deux­points (:) sont pris en charge sous Unix/ Li­nux. Les noms de fi­chiers de script et des che­mins com­plets conte­nant des vir­gules sont eux aus­si pris en charge. Le pa­ra­mètre - Li­te­ralPath per­met de sup­pri­mer le dé­ve­lop­pe­ment des ca­rac­tères gé­né­riques pour les ap­plets de com­mande de na­vi­ga­tion ( Set- lo­ca­tion, no­tam­ment). La com­mande Get- ChildI­tem – l’équi­valent ou presque en Po­werS­hell de ls sous Posix ou dir sous Win­dows – a été mise à jour en vue de fonc­tion­ner de ma­nière plus nor­ma­li­sée avec des ap­pels de type com­mandes na­tives POSIX ( comme les - R) et Win­dows ( dir / S). GetC­hildI­tem re­tourne dé­sor­mais les liens sym­bo­liques ren­con­trés lors d’une re­cherche ré­cur­sive et a même été en­ri­chie d’un pa­ra­mètre (- Fol­lowSym­link) lui per­met­tant de les tra­ver­ser à la de­mande. L’uti­li­sa­tion du four­nis­seur Fi­lesys­tem peut être ac­ti­vée à par­tir d’un che­min UNC. Le cd sans ar­gu­ment se com­porte main­te­nant comme cd ~ et, point non né­gli­geable, Po­werS­hell Core au­to­rise l’uti­li­sa­tion de che­mins d’une lon­gueur de plus de 260 ca­rac­tères.

Ré­tro­com­pa­ti­bi­li­té avec Win­dows Po­werS­hell

L’ob­jec­tif de Mi­cro­soft est de faire en sorte que Po­werS­hell Core reste aus­si com­pa­tible que pos­sible avec Win­dows Po­werS­hell. Po­werS­hell Core s’ap­puie pour ce­la sur le . NET Stan­dard 2.0 pour as­su­rer la com­pa­ti­bi­li­té bi­naire avec des as­sem­blys . NET exis­tants. Un grand nombre de mo­dules Po­werS­hell

dé­pen­dant de ces as­sem­blys, le . NET Stan­dard per­met à . NET Core de les uti­li­ser. Po­werS­hell Core in­clut éga­le­ment une mé­thode heu­ris­tique d’exa­men des dos­siers connus tel que ce­lui où se trouve gé­né­ra­le­ment le Glo­bal Assembly Cache sur le disque et de re­cherche des dé­pen­dances des dll du . NET Fra­me­work. Mi­cro­soft a, semble- t- il, tout mis en oeuvre afin de ga­ran­tir que le lan­gage Po­werS­hell et les mo­dules in­té­grés tels que Mi­cro­soft. Po­werS­hell. Ma­na­ge­ment, Mi­cro­soft. Po­werS­hell. Uti­li­ty ou autres fonc­tionnent de la même ma­nière que dans Win­dows Po­werS­hell. Dans quelques cas de fi­gure, et ce en rai­son d’une dé­pen­dance man­quante dans les couches . NET sous- ja­centes, la fonc­tion­na­li­té a été sup­pri­mée. La plu­part des mo­dules « purs » Win­dows ( DnsC­lient, Hy­per- V, NetTCPIP, Sto­rage…) et ceux des autres pro­duits Mi­cro­soft comme Azure ou Of­fice n’ont pas en­core été ex­pli­ci­te­ment dé­pla­cés vers. NET Core. L’équipe Po­werS­hell y tra­vaille, avec les équipes des lo­gi­ciels concer­nés pour va­li­der et dé­pla­cer leurs mo­dules exis­tants vers Po­werS­hell Core. Grace à. NET Stan­dard et CDXML, la plu­part de ces mo­dules fonc­tionnent dans Po­werS­hell Core, mais ils ne sont ni va­li­dés ni pris en charge d’un point de vue of­fi­ciel. Si vous sou­hai­tez uti­li­ser des mo­dules Win­dows Po­werS­hell dans Po­werS­hell Core, ins­tal­lez le mo­dule Win­dowsPSMo­du­lePath et ajou­tez le Win­dows Po­werS­hell PSMo­du­lePath à Po­werS­hell Core PSMo­du­lePath. Voi­ci comment pro­cé­der, après avoir té­lé­char­gé Win­dowsPSMo­du­lePath de­puis la Po­werS­hell Gal­le­ry : # Ajou­tez le pa­ra­mètre - Scope Cur­rentU­ser si vous n’êtes pas ad­mi­nis­tra­teur Ins­tall- Mo­dule Win­dowsPSMo­du­lePath - Force Exé­cu­tez l’ap­plet de com­mande Add- Win­dowsPSMo­du­lePath qui ajou­te­ra di­rec­te­ment Win­dows Po­werS­hell PSMo­du­lePath à Po­werS­hell Core : Add- Win­dowsPSMo­du­lePath Pour que ce­la soit sys­té­ma­tique, ajou­tez la ligne pré­cé­dente à un fi­chier de pro­fil Po­werS­hell.

Les mo­dules com­pa­tibles avec les deux ver­sions

Cer­tains mo­dules sont in­té­grés na­ti­ve­ment à Po­wers­hell Core. En voi­ci la liste don­née par Mi­cro­soft : CimCmd­lets, Mi­cro­soft. Po­werS­hell. Ar­chive, Mi­cro­soft. Po­werS­hell. Dia gnos t i c s , Mi­cro s of t . Po­werS­hell. Host, Mi­cro­soft. Po­werS­hell. Ma­na­ge­ment, Mi­cro­soft. Po­werS­hell. Se­cu­ri­ty, Mi­cro­soft. Po­werS­hell. Uti­li­ty, Mi­cro­soft. WSMan. Ma­na­ge­ment, Pa­cka­geMa­na­ge­ment, Po­werS­hellGet, PSDe­si­redS­ta­teCon­fi­gu­ra­tion, PSDiag­nos­tics et PSRead­Line. Il n’y a, pour le mo­ment, au­cune ga­ran­tie quant au par­fait fonc­tion­ne­ment des mo­dules first- par­ty de Mi­cro­soft avec Po­werS­hell Core. Les mo­dules concer­nés sont ceux in­té­grés à Win­dows ( par­ties client et ser­veur), les mo­dules in­té­grés à des pro­duits Mi­cro­soft tels que Ex­change ou Sha­rePoint ou en­core les mo­dules de la Po­werS­hell Gal­le­ry ( https:// www. po­wer­shell­gal­le­ry. com/). Con­crè­te­ment, la plu­part des com­mandes et donc des scripts écrits en Win­dows Po­werS­hell ( toutes ver­sions) fonc­tionnent, mais vous pou­vez ren­con­trer des pro­blèmes de temps en temps avec cer­taines ins­truc­tions ou pa­ra­mètres. Ce­la de­vrait se ré­soudre pro­gres­si­ve­ment grâce à l’ac­tion conju­guée de Mi­cro­soft et de la com­mu­nau­té Po­werS­hell. Les API par­ta­gées entre . NET Core et le . NET Fra­me­work sont dé­fi­nies dans le cadre de . NET Stan­dard ( cf https:// docs. mi­cro­soft. com/ fr- fr/ dot­net/ stan­dard/ net- stan­dard).

Res­pect de la casse

Li­nux et Mac OS X ont ten­dance à res­pec­ter la casse, ce qui n’est pas vrai­ment le cas de Win­dows.

En règle gé­né­rale, Po­werS­hell ne res­pecte pas la casse, sauf cas par­ti­cu­lier et en le spé­ci­fiant ( en ajou­tant c de­vant les opé­ra­teurs, par exemple : - cmatch au lieu de - match, - clike au lieu de - like, etc). Comme les va­riables d’en­vi­ron­ne­ment res­pectent for­cé­ment la casse sous Mac OS X et Li­nux, la casse de la va­riable d’en­vi­ron­ne­ment PSMo­du­lePath a été nor­ma­li­sée. La cmd­let Im­port- Mo­dule, en re­vanche, ne res­pecte pas la casse lorsque vous spé­ci­fiez le nom d’un mo­dule à char­ger.

Prise en charge de Do­cker

Po­werS­hell Core ajoute la prise en charge des conte­neurs Do­cker pour les prin­ci­pales pla­tes­formes, ce­ci in­cluant plu­sieurs dis­tri­bu­tions Li­nux, Win­dows Ser­ver Core et Na­no Ser­ver. La liste ex­haus­tive est dis­po­nible à l’adresse https:// hub. do­cker. com/ r/ mi­cro­soft/ po­wers­hell/. Vous trou­ve­rez plus d’in­for­ma­tions sur Do­cker et Po­werS­hell Core à l’adresse https:// gi­thub. com/ Po­werS­hell/ Po­werS­hell/ tree/ mas­ter/ do­cker.

En­co­dage par dé­faut en UTF- 8

Jusque- là, les ap­plets de com­mande Win­dows Po­werS­hell telles que Get- Content ou Set- Content uti­li­saient des en­co­dages dif­fé­rents comme ASCII et UTF- 16. Ce­la gé­né­rait, du coup, des pro­blèmes lorsque l’on as­so­ciait ( via le pipe) des ap­plets de com­mande sans pré­ci­ser l’en­co­dage à em­ployer. Les plates- formes POSIX uti­lisent en gé­né­ral l’en­co­dage UTF- 8 sans marque d’ordre d’oc­tet comme en­co­dage par dé­faut pour les fi­chiers texte. D’autres ou­tils et ap­pli­ca­tions Win­dows passent de l’en­co­dage UTF- 16 à l’en­co­dage UTF- 8 sans marque d’ordre d’oc­tet. Po­werS­hell Core mo­di­fie donc l’en­co­dage par dé­faut afin de se confor­mer à la ma­jo­ri­té des dis­tri­bu­tions POSIX. Plus con­crè­te­ment, toutes les ap­plets de com­mande in­té­grées em­ployant le pa­ra­mètre - En­co­ding uti­lisent la va­leur par dé­faut UTF8NoBOM. Les ap­plets de com­mande af­fec­tées par cette mo­di­fi­ca­tion sont Add- Content, Ex­port- Clixml, Ex­port- Csv, Ex­port- PSSes­sion, For­matHex, Get- Content, Im­por tCsv, New- Mo­du­leMa­ni­fest, Out- File, Se­lect- String, SendMailMe­s­sage et Set- Content. Ces com­mand­lets ont éga­le­ment été mises à jour afin que le pa­ra­mètre - En­co­ding ac­cepte uni­ver­sel­le­ment Sys­tem. Text. En­co­ding. La va­leur par dé­faut de la va­riable de pré­fé­rence $ Out­putEn­co­ding a elle aus­si été rem­pla­cée par UTF- 8.

Cycle de vie et sup­port de Po­werS­hell Core

Po­werS­hell Core est pu­blié sous li­cence MIT. Ce­la veut dire qu’en l’ab­sence d’un contrat de sup­port payant, les uti­li­sa­teurs ne peuvent bé­né­fi­cier que du sup­port de la com­mu­nau­té, sans au­cune ga­ran­tie de ré­ac­ti­vi­té ou de li­vrai­son de cor­rec­tif de la part de l’édi­teur. Bien que le sup­port de Po­werS­hell Core ne soit pas in­clus par dé­faut dans les contrats de li­cence Win­dows et Win­dows Ser­ver, il est néan­moins pris en charge dans des contrats de sup­port Mi­cro­soft clas­siques tels que Pre­mier, les contrats En­tre­prise Mi­cro­soft et la Mi­cro­soft Soft­ware As­su­rance. Il est aus­si en­vi­sa­geable de payer pour ob­te­nir un sup­port spé­ci­fique pour Po­werS­hell Core. Vous dis­po­sez d’un sup­port de la com­mu­nau­té sur Gi­tHub, où vous pou­vez si­gna­ler un pro­blème, un bogue ou une de­mande de nou­velle fonc­tion­na­li­té. Au­cune ga­ran­tie n’est as­su­rée quant à la prise en compte du dit pro­blème. Po­werS­hell Core adopte la po­li­tique de sup­port mo­derne Mi­cro­soft ( si­mi­laire à celle de Win­dows 10). Cette po­li­tique de sup­port est des­ti­née à main­te­nir les clients à jour avec les der­nières ver­sions. La branche Po­werS­hell Core ver­sion 6. x se­ra mise à jour en­vi­ron une fois tous les six mois. Vous de­vrez en re­vanche ef­fec­tuer la mise à jour de Po­werS­hell Core dans les six mois sui­vant la pu­bli­ca­tion de chaque nou­velle ver­sion mi­neure afin de pou­voir conti­nuer à pro­fi­ter du sup­port de ver­sion. Ce­la im­plique éga­le­ment que Mi­cro­soft pré­vienne ses clients 12 mois avant la fin du sup­port d’un pro­duit. Au fi­nal, Po­werS­hell Core de­vrait suivre l’ap­proche de main­te­nance à long terme ( LTSB pour Long Term Ser­vi­cing Branch) où seules la main­te­nance et les mises à jour de sé­cu­ri­té res­te­ront en sup­port sur une branche/ ver­sion spé­ci­fique de 6. x. ❍

L’image choi­sie pour le pre­mier écran de l’ins­tal­la­tion de Po­werS­hell Core in­dique que Mi­cro­soft semble en­fin vou­loir sor­tir des cré­neaux, avec un pe­tit clin d’oeil geek/ open source.

Vous trou­ve­rez les dif­fé­rentes ver­sions de Po­werS­hell Core dis­po­nibles au té­lé­char­ge­ment à l’adresse https:// gi­thub. com/ po­wers­hell/ po­wers­hell

Vi­sual Stu­dio pré­sente le double avan­tage d’être dis­po­nible sur tous les OS et de pos­sé­der une aide in­té­grée pour Po­werS­hell.

Comme avec la ver­sion Win­dows, vous n’y cou­pe­rez pas. Vous de­vrez mettre à jour l’aide après l’ins­tal­la­tion en exé­cu­tant la com­mande Up­date- Help pour en pro­fi­ter plei­ne­ment.

Newspapers in French

Newspapers from France

© PressReader. All rights reserved.