La nouvelle version majeure du shell introduit bon nombre de nouveautés, dont la plus importante est le passage à .NET Core 2.x à 3.1, provoquant un afflux d’API du framework .NET. Résultat, une compatibilité beaucoup plus importante avec les modules PowerShell existants de Windows.
« Cela comprend de nombreux modules sous Windows qui nécessitent des fonctionnalités d'interface graphique comme Out-GridView et Show-Command, ainsi que de nombreux modules de gestion des rôles livrés avec Windows », indique Microsoft.
PowerShell 7 introduit la parallélisation du pipeline avec ForEach-Object -Parallel, les opérateurs de chaîne de pipeline (&& et ||), l’opérateur ternaire (a ? b : c), d'assignation nulle et de coalescence (?? et ??=), les notifications de nouvelle version, une nouvelle « vue simplifiée et dynamique des erreurs » ou encore la commande Get-Error.
Les systèmes pris en charge sont nombreux, mais uniquement en x64 :
- Windows : 7, 8.1 et 10, Server 2008 R2, 2012, 2012 R2, 2016 et 2019
- macOS 10.13 et versions ultérieures
- Linux : RHEL/CentOS 7, Fedora 29, Debian 9, Ubuntu 16.04, openSUSE 15, Alpine Linux 3.8 et versions ultérieures
Microsoft précise que si Arch et Kali Linux ne sont pas officiellement supportés, la communauté fournit déjà des paquets. Les moutures ARM32 et ARM64 de Debian sont prises en charge, de même que la version ARM64 d’Alpine Linux.
Notez que PowerShell 7 représente l’unification des branches de développement. Le projet PowerShell Core en tant que tel n’existe plus, exactement comme le prévoit Microsoft avec le framework .NET 7. Bien que la mention Core puisse encore apparaître, ce sera uniquement dans un contexte de différenciation avec Windows PowerShell.
Commentaires (26)
#1
Pour ceux qui ont déjà Powershell 6, il suffit de taper dans une console autre que PowerShell 6 :
dotnet tool update –global PowerShell
Si vous êtes encore sous PowerShell 5 (ou précédent) :
dotnet tool install –global PowerShell
Dans tous les cas, .NET Core 3.1 doit d’abord avoir été installé.
Source :
https://docs.microsoft.com/en-us/powershell/scripting/install/installing-powersh…
#2
(Vraie question sérieuse) Est-ce que quelqu’un, qui utilise PowerShell sous Linux, peut me donner une raison ou un avantage à l’utiliser plutot que Bash(ZSH, Fish, ) ?
#3
#4
#5
Encore faut t’il que que Dotnet soit installé….
C’est le cas sur Windows, sous Linux ce n’est pas le cas par défaut.
#6
Personnellement, je ne fais pratiquement que du Linux et je trouve PowerShell très intéressant. Par rapport aux shells classiques les fonctionnalité sont clairement un cran en dessus, avec notamment des données structurées et l’approche objet.
Cependant, pour l’instant, je garde juste un œil dessus car en pratique je n’ai pas trouvé le temps de m’y investir.
#7
#8
Quelqu’un sait comment on fait pour configurer un colorscheme avec WindowsTerminal (du store) ? J’ai bien essayé de modifier le profile.json… mais rien y fait, j’ai toujours le fond noir et les couleurs par défaut…
#9
Merci
" />
#10
Merci pour vos réponses, effectivement, je n’ai absolument pas l’utilité de PS dans mon cas. Workstations linux, tous mes serveurs linux, je pratiques bash depuis 10 ans et écris tous mes scripts en python (objet aussi), voir meme en go pour des gros scripts destinés à tourner avec cron.
#11
On est obligé de l’installer à la main ? ça ne serait pas fournit via windows update ou dans la version de base win 10 20H2 … ?
#12
Le jour où l’on verra une console RSAT sous GNU/Linux, capable de gérer un AD sous smbd/nmbd, on pourra considérer que microsoft fait réellement un petit effort d’ouverture vers le libre.
#13
#14
Ce n’est pas faisable via WinRM et Powershell justement?
#15
Il faut comparer l’équivalent.
L’équivalent à Powershell Core sous Unix, c’est Python, pas Bash.
Le gros avantage reste le concept objet/Méthode qui permet une réutilisation.
#16
#17
Un outil du genre Ansible est redoutablement efficace pour répondre à un besoin de déploiement sur un parc de ce type.
Surtout qu’il permet de ne pas avoir connaissance du secret car pouvant s’interfacer avec un solution de type Vault ou même tout simplement chiffrer les fichiers de variables.
#18
au vu des commentaires, PS à l’air sympa… mais j’arrive pas du tout à accrocher.
et comme les serveurs windows auxquels j’ai accès ne sont pas en version core, je peux toujours me démerder avec du batch et/ou quelques clics… ce qui ne m’aide pas à m’y intéresser plus que ça (et sous linux, je reste sur du bash ou sh, qui sont par défaut sur les machines)
#19
Pour vous donner un exemple d’utilisation, avec DevOps, on peut faire des build automatique avec des déploiements automatique.
Et DevOps utilise des scripts powershell pour faire tout ça. En fait, c’est plutôt à vous de créer ces scripts. Vous pouvez le faire avec des machines sous azure, des machines physique ou des dockers via des agents DevOps.
Et ces différentes machines peuvent être sous Windows, Linux ou Mac OS.
En bref, ils continuent à attirer de nouveaux clients sous azure avec de nouvelles possibilités tout en concurrençant encore plus AWS.
Il n’y a que peu d’intérêt pour ceux qui ont déjà leur propre système.
#20
Idem.
" />
Pour avoir un peu essayé, je trouve la syntaxe de PS imbuvable… des commandes à rallonge avec des accolades, des crochets, des majuscules dans les noms…
J’ai essayé une fois d’installer un windows server core… j’ai très vite déchanté et je me suis empressé d’installer les RSAT
#21
Azure a détourné le nom de la démarche DevOps pour en faire une simple liste d’outils de CICD ?
" />
#22
#23
#24
#25
Désolé, j’aurais pu être plus précis.
#26