Nouveautés de PowerShell 7.1

Article
06/21/2023

Le 11 novembre 2020, nous avons annoncé la disponibilité générale de PowerShell 7.1. En s'appuyant sur les bases établies dans PowerShell 7.0, nos efforts se sont concentrés sur les questions soulevées par la communauté et comprennent un certain nombre d'améliorations et de corrections. Nous nous engageons à faire en sorte que PowerShell reste une plateforme stable et performante.

PowerShell 7.1 comprend les fonctionnalités, les mises à jour et les changements cassants suivants.

PSReadLine 2.1.0, qui comprend IntelliSense prédictif
Publication de PowerShell 7.1 sur le Microsoft Store
Mise à jour des packages d’installation pour les nouvelles versions de système d’exploitation avec prise en charge d’ARM64
Officialisation de 4 nouvelles fonctionnalités expérimentales et 2 fonctionnalités expérimentales
Divers changements cassants pour améliorer l’utilisabilité

Pour obtenir la liste complète des changements, consultez CHANGELOG dans le dépôt GitHub.

PSReadline 2.1.0

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

Package d’installation Microsoft Store

PowerShell 7.1 a été publié sur le Microsoft Store. Vous trouverez la version PowerShell sur le site Web du Microsoft Store ou dans l’application Store de Windows.

Avantages du package Microsoft Store :

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

Notes

Les paramètres de configuration au niveau du système, stockés dans $PSHOME, ne peuvent pas être modifiés. 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 programmes d’installation

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

Consultez les instructions d’installation pour votre système d’exploitation par défaut :

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

Bien qu’ils ne soit pas officiellement pris en charge, la communauté a également fourni des packages pour Arch et Kali Linux.

Notes

Debian 10+, CentOS 8+, Ubuntu 20.04, Alpine et Arm ne prennent actuellement pas en charge la communication à distance WinRM. Pour plus d’informations sur la configuration de la communication à distance basée sur SSH, consultez Communication à distance PowerShell via SSH.

Fonctionnalités expérimentales

Pour plus d’informations sur les fonctionnalités expérimentales, consultez Utilisation des fonctionnalités expérimentales.

Les fonctionnalités expérimentales suivantes sont maintenant devenues des fonctionnalités standard 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 à toutes les applets de commande *-PSBreakpoint. Le paramètre Runspace spécifie un objet Runspace pour interagir avec des points d’arrêt dans l’instance d’exécution spécifiée.
PSNativePSPathResolution - Cette fonctionnalité vous permet de passer des chemins de fournisseur PowerShell à des commandes natives qui ne prennent pas en charge la syntaxe de chemin de PowerShell.
PSCultureInvariantReplaceOperator - Lorsque l’opérande gauche dans une instruction opérateur -replace n’est pas une chaîne, cet opérande est converti en chaîne. Lorsque la fonctionnalité est activée, la conversion n’utilise pas les paramètres de culture pour la conversion de chaînes.
PSSubsystemPluginModel permet de prendre en charge les futurs plug-ins IntelliSense prédictif.

Dernières modifications et améliorations

Changement de comportement pour la comparaison de chaînes dans la version 5.0 de .NET

PowerShell 7.1 repose sur la version 5.0 de .NET, qui a introduit le changement cassant suivant :
- Changements de comportement lors de la comparaison de chaînes sur .NET 5 et les versions plus récentes
À compter de la version 5.0 de .NET, les comparaisons de chaînes à culture invariante ignorent les caractères de contrôle non imprimables.

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 de $? pour ne pas être $false lorsque la commande native écrit dans stderr (#13395)

Il est courant que les commandes natives écrivent dans stderr sans avoir à indiquer un échec. Avec ce changement, $? a la valeur $false uniquement lorsque la commande native a également un code de sortie différent de zéro. Ce changement n’est pas lié à la fonctionnalité expérimentale PSNotApplyErrorActionToStderr.
Configuration de $ErrorActionPreference pour ne pas affecter la sortie stderr des commandes natives (#13361)

Il est courant que les commandes natives écrivent dans stderr sans avoir à indiquer un échec. Avec ce changement, la sortie stderr est toujours capturée dans les objets ErrorRecord, mais le runtime n’applique plus $ErrorActionPreference si le ErrorRecord provient d’une commande native.
Renommez-le -FromUnixTime-UnixTimeSecondsGet-Date pour autoriser l’entrée de temps Unix (#13084) (Merci @aetos382!)

Le paramètre -FromUnixTime a été ajouté pendant 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 est représentée 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 DateHeure.
```
Get-Date -UnixTimeSeconds 1577836800

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

Avec ce changement, les paramètres nommés de la projection sont déplacés à la fin de la liste de paramètres afin qu’ils soient liés une fois que tous les paramètres nommés explicitement spécifiés sont liés. La liaison de paramètre pour les fonctions simples ne génère pas d’erreur quand un paramètre nommé spécifié est introuvable. Les paramètres nommés inconnus sont liés au paramètre $args de la fonction simple. Le déplacement de la projection à 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 il s’agit du troisième argument dans la liste d’arguments. # # Donc, il finit par être placé dans « $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 d’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
```
Rendre le paramètre de -Qualifier commutateur non positionnel pour Split-Path (#12960) (Merci @yecril71pl!)
Résolvez le répertoire de travail comme chemin littéral pour Start-Process le moment où il n’est pas spécifié (#11946) (merci) @NoMoreFood!)
Rendre -OutFile le paramètre dans les applets de commande web à utiliser comme -LiteralPath (#11701) (Merci @iSazonov!)
Correction de la liaison de paramètre de chaîne pour BigInteger les littéraux numériques (#11634) (Merci @vexx32!)
Sur Windows, Start-Process crée un environnement de processus avec toutes les variables d’environnement de la session actuelle, à l’aide -UseNewEnvironment de créer un nouvel environnement de processus par défaut (#10830) (merci) @iSazonov!)
Résultat non wrappé dans PSObject lors de la conversion de ScriptBlock en délégué (#10619)

Quand un ScriptBlock est converti en type délégué à utiliser dans un contexte C#, le wrapping du résultat dans un PSObject pose des problèmes inutiles :
- Lorsque la valeur est convertie en type de retour délégué, PSObject n’est pas wrappé par essence. Donc PSObject n’est pas nécessaire.
- Lorsque le type de retour délégué est object, il est wrappé dans un PSObject, ce qui rend difficile son utilisation dans le code C#.
Après ce changement, l’objet retourné est l’objet sous-jacent.