Nouveautés de PowerShell 7.1

Le 11 novembre 2020, nous avons annoncé la disponibilité générale de PowerShell 7.1. S’appuyant sur les fondations établies dans PowerShell 7.0, nos efforts se sont concentrés sur les problématiques communautaires et incluent de nombreuses améliorations et corrections. Nous nous engageons à garantir que PowerShell reste une plateforme stable et performante.

PowerShell 7.1 inclut les fonctionnalités, mises à jour et changements urgents suivants.

PSReadLine 2.1.0, qui inclut Predictive IntelliSense
PowerShell 7.1 a été publié sur le Microsoft Store
Paquets d’installation mis à jour pour les nouvelles versions du système d’exploitation avec la prise en charge d’ARM64
4 nouvelles fonctionnalités expérimentales et 2 fonctionnalités expérimentales promues au grand public
Plusieurs changements majeurs pour améliorer l’ergonomie

Pour obtenir la liste complète des modifications, consultez la changeLOG dans le référentiel GitHub.

PSReadLine 2.1.0

PowerShell 7.1 inclut également PSReadLine 2.1.0. Cette version inclut Predictive IntelliSense. Pour plus d’informations sur la fonctionnalité Predictive IntelliSense, consultez l’annonce sur le blog PowerShell.

Paquet d’installation du Microsoft Store

PowerShell 7.1 a été publié sur le Microsoft Store. Vous pouvez trouver la version PowerShell sur le site du Microsoft Store ou dans l’application Store sous Windows.

Avantages du package Microsoft Store :

Mises à jour automatiques intégrées à Windows
S’intègre avec d’autres mécanismes de distribution logicielle comme Intune et SCCM

Note

Aucun réglage de configuration au niveau système stocké $PSHOME dans ne peut être modifié. Cela comprend la configuration WSMAN. Cette stratégie empêche les sessions à distance de se connecter aux installations basées sur le magasin de PowerShell. Les configurations au niveau de l’utilisateur et l’accès à distance SSH sont pris en charge.

Autres installateurs

Pour plus d’informations up-toà date sur les systèmes d’exploitation pris en charge et le cycle de vie du support, consultez le cycle de vie de support PowerShell.

Consultez les instructions d’installation de votre système d’exploitation préféré :

De plus, PowerShell 7.1 prend en charge les versions ARM32 et ARM64 de Debian, Ubuntu et ARM64 Alpine Linux.

Bien que non officiellement prise en charge, la communauté a également fourni des packages pour Arch et Kali Linux.

Note

Debian 10+, CentOS 8+, Ubuntu 20.04, Alpine et Arm ne supportent actuellement pas le système à distance de WinRM. Pour plus de détails sur la configuration de la télécommande basée sur SSH, voir PowerShell Remoting over SSH.

Fonctionnalités expérimentales

Pour plus d’informations sur les fonctionnalités expérimentales, consultez Using Experimental Features.

Les fonctionnalités expérimentales suivantes sont désormais des fonctionnalités grand public dans cette version :

Les fonctionnalités expérimentales suivantes ont été ajoutées dans cette version :

Microsoft.PowerShell.Utility.PSManageBreakpointsInRunspace
- PowerShell 7.1 étend cette fonctionnalité expérimentale pour ajouter le paramètre Runspace à tous *-PSBreakpoint les cmdlets. Le paramètre Runspace spécifie qu’un objet Runspace interagit avec les points d’arrêt dans l’espace spécifié.
PSNativePSPathResolution - Cette fonctionnalité vous permet de passer des chemins fournisseurs PowerShell vers des commandes natives qui ne supportent pas la syntaxe des chemins PowerShell.
PSCultureInvariantReplaceOperator - Lorsque l’opérande de gauche dans une -replace instruction opérateur n’est pas une chaîne, cet opérande est converti en chaîne. Avec cette fonctionnalité activée, la conversion n’utilise pas les paramètres de culture pour la conversion de chaînes.
PSSubsystemPluginModel pose les bases pour supporter les futurs plug-ins Predictive IntelliSense.

Changements et améliorations de rupture

Le comportement de comparaison de chaînes a changé dans .NET 5.0

PowerShell 7.1 est construit sur .NET 5.0, qui a introduit le changement décisif suivant :
- Le comportement change lors de la comparaison de chaînes sur .NET 5+
Depuis .NET 5.0, les comparaisons de chaînes invariantes par culture ignorent les caractères de contrôle non imprimants.

Par exemple, les deux chaînes suivantes sont considérées comme identiques :
```
# Escape sequence "`a" is Ctrl-G or [char]7
'Food' -eq "Foo`ad"
```
```
True
```
Correction $? pour ne pas être $false lorsque la commande native écrit à stderr (#13395)

Il est courant que des commandes natives écrivent sans stderr intention d’indiquer une défaillance. Avec ce changement $? , il est réglé uniquement $false lorsque la commande native possède également un code de sortie non nul. Ce changement n’a aucun lien avec la caractéristique PSNotApplyErrorActionToStderrexpérimentale .
Ne pas $ErrorActionPreference affecter stderr la sortie des commandes natives (#13361)

Il est courant que des commandes natives écrivent sans stderr intention d’indiquer une défaillance. Avec ce changement, stderr la sortie est toujours capturée dans les objets ErrorRecord, mais l’exécution ne s’applique $ErrorActionPreference plus si l’ErrorRecord provient d’une commande native.
Renommer -FromUnixTime en -UnixTimeSeconds on Get-Date pour permettre l’entrée en temps Unix (#13084) (Merci @aetos382!)

Le -FromUnixTime paramètre a été ajouté lors de la version 7.1-preview.2. Le paramètre a été renommé pour mieux correspondre au type de données. Ce paramètre prend une valeur entière qui représente en secondes depuis le 1er janvier 1970, 0:00:00.

Cet exemple convertit une heure Unix (représentée par le nombre de secondes depuis le 01-01-1970 0:00:00) en DateTime.
```
Get-Date -UnixTimeSeconds 1577836800

Wednesday, January 01, 2020 12:00:00 AM
```
Autoriser un paramètre nommé explicitement spécifié à remplacer le même que celui du splatting de la table de hachage (#13162)

Avec ce changement, les paramètres nommés issus du splatting sont déplacés à la fin de la liste des paramètres afin qu’ils soient liés après que tous les paramètres nommés explicitement spécifiés soient liés. La liaison de paramètres pour des fonctions simples ne génère pas d’erreur lorsqu’un paramètre nommé spécifié n’est pas trouvé. Les paramètres nommés inconnus sont liés au $args paramètre de la fonction simple. Déplacer le splatting à la fin de la liste d’arguments change l’ordre dans lequel les paramètres apparaissent dans $args.

Par exemple:
```
function SimpleTest {
    param(
        $Name,
        $Path
    )
    "Name: $Name; Path: $Path; Args: $args"
}
```
Dans le comportement précédent, MyPath n’est pas lié à -Path car c’est le troisième argument de la liste des arguments. ## Donc ça finit par être bourré dans le « $args » avec Blah = "World"
```
PS> $hash = @{ Name = "Hello"; Blah = "World" }
PS> SimpleTest @hash "MyPath"
Name: Hello; Path: ; Args: -Blah: World MyPath
```
Avec ce changement, les arguments de @hash sont déplacés à la fin de la liste des arguments. MyPath devient le premier argument de la liste, donc il est lié à -Path.
```
PS> SimpleTest @hash "MyPath"
Name: Hello; Path: MyPath; Args: -Blah: World
```
Faites en sorte que le paramètre -Qualifier de l’interrupteur ne soit pas positionnel pour Split-Path (#12960) (Merci @yecril71pl!)
Résolvez le répertoire de travail comme un chemin littéral pour Start-Process quand il n’est pas spécifié (#11946) (Merci @NoMoreFood!)
Faire fonctionner -OutFile le paramètre dans les cmdlets web comme -LiteralPath ça (#11701) (Merci @iSazonov!)
Correction de la liaison des paramètres de chaîne pour BigInteger les littéraux numériques (#11634) (Merci @vexx32!)
Sous Windows, Start-Process crée un environnement de processus avec toutes les variables d’environnement de la session courante, en utilisant -UseNewEnvironment crée un nouvel environnement de processus par défaut (#10830) (Merci @iSazonov!)
Ne pas emballer le résultat return lors PSObject de la conversion de a ScriptBlock en délégué (#10619)

Lorsque a ScriptBlock est converti en type délégué à utiliser dans le contexte C#, envelopper le résultat dans a PSObject apporte des problèmes inutiles :
- Lorsque la valeur est convertie en type de retour délégué, le PSObject déplié est essentiellement déplié. Donc c’est PSObject inutile.
- Lorsque le type de retour de délégué est object, il est enveloppé dans un PSObject , ce qui rend le travail difficile à utiliser en C#.
Après ce changement, l’objet retourné devient l’objet sous-jacent.

Last updated on 2021-10-04

Partager via