Novedades de PowerShell 7.1

Artículo
05/09/2024

El 11 de noviembre de 2020, anunciamos la disponibilidad general de PowerShell 7.1. Basándose en los cimientos establecidos en PowerShell 7.0, nuestros esfuerzos se centraron en los problemas de la comunidad y incluyen una serie de mejoras y correcciones. Nos comprometemos a asegurarnos de que PowerShell siga siendo una plataforma estable y eficiente.

PowerShell 7.1 incluye las características, las actualizaciones y los cambios importantes que se indican a continuación.

PSReadLine 2.1.0, que incluye IntelliSense predictivo.
PowerShell 7.1 se ha publicado en Microsoft Store.
Paquetes de instalador actualizados para las nuevas versiones de SO con compatibilidad para ARM64.
4 nuevas características experimentales y 2 características experimentales promovidas a estándares.
Varios cambios importantes para mejorar la usabilidad.

Para ver la lista completa de cambios, consulte el REGISTRO DE CAMBIOS en el repositorio de GitHub.

PSReadLine 2.1.0

PowerShell 7.1 también incluye PSReadLine 2.1.0. Esta versión incluye IntelliSense predictivo. Para más información sobre la característica de IntelliSense predictivo, consulte el anuncio en el blog de PowerShell.

Paquete del instalador de Microsoft Store.

PowerShell 7.1 se ha publicado en Microsoft Store. Puede encontrar la versión de PowerShell en el sitio web de Microsoft Store o en la aplicación de la tienda de Windows.

Ventajas del paquete de Microsoft Store:

Actualizaciones automáticas integradas en Windows
Se integra con otros mecanismos de distribución de software como Intune y SCCM.

Nota

No se pueden modificar las opciones de configuración de nivel de sistema almacenadas en $PSHOME. Esto incluye la configuración de WSMAN. Esto impide que las sesiones remotas se conecten a instalaciones basadas en el almacén de PowerShell. Se admiten las configuraciones de nivel de usuario y la comunicación remota de SSH.

Otros instaladores.

Para más información actualizada sobre los sistemas operativos compatibles y el ciclo de vida de soporte técnico, consulte Ciclo de vida de soporte técnico de PowerShell Core.

Consulte las instrucciones de instalación del sistema operativo que prefiera:

Además, PowerShell 7.1 admite los tipos ARM32 y ARM64 de Debian, Ubuntu y ARM64 Alpine Linux.

Aunque no se admite oficialmente, la comunidad también ha proporcionado paquetes para Arch y Kali Linux.

Nota

Debian 10+, CentOS 8+, Ubuntu 20.04, Alpine y ARM actualmente no admiten la comunicación remota de WinRM. Para más información sobre cómo configurar la comunicación remota basada en SSH, consulte Comunicación remota de PowerShell a través de SSH.

Características experimentales

Para más información sobre las características experimentales, consulte Uso de características experimentales en PowerShell.

Las características experimentales siguientes ya son estándares en esta versión:

Las características experimentales siguientes se han agregado en esta versión:

Microsoft.PowerShell.Utility.PSManageBreakpointsInRunspace
- PowerShell 7.1 amplía esta característica experimental para agregar el parámetro Runspace a todos los cmdlets de *-PSBreakpoint. El parámetro Runspace especifica un objeto Runspace para interactuar con los puntos de interrupción del espacio de ejecución especificado.
PSNativePSPathResolution: esta característica permite pasar las rutas de acceso del proveedor de PowerShell a comandos nativos que no son compatibles con la sintaxis de rutas de acceso de PowerShell.
PSCultureInvariantReplaceOperator: cuando el operando izquierdo de una instrucción de operador -replace no es una cadena, ese operando se convierte en una cadena. Con la característica habilitada, la conversión no utiliza la configuración de referencia cultural para la conversión de la cadena.
PSSubsystemPluginModel establece las bases de la compatibilidad con futuros complementos de IntelliSense.

Últimos cambios y mejoras

Comportamiento de comparación de cadenas cambiado en .NET 5.0

PowerShell 7.1 se basa en .NET 5.0, que introdujo el siguiente cambio rotundo:
- Cambios de comportamiento al comparar cadenas en .NET 5 +
A partir de .NET 5.0, las comparaciones de cadenas de referencia cultural invariable omiten los caracteres de control no imprimibles.

Por ejemplo, las dos cadenas siguientes se consideran idénticas:
```
# Escape sequence "`a" is Ctrl-G or [char]7
'Food' -eq "Foo`ad"
```
```
True
```
Se ha corregido $? para que no sea $false cuando el comando nativo escriba en stderr (#13395).

Es habitual que los comandos nativos escriban en stderr sin intención de indicar un error. Con este cambio, $? solo se establece en $false cuando el comando nativo también tiene un código de salida distinto de cero. Este cambio no está relacionado con la característica experimental PSNotApplyErrorActionToStderr.
Se ha permitido que $ErrorActionPreference no afecte a la salida stderr de los comandos nativos (#13361).

Es habitual que los comandos nativos escriban en stderr sin intención de indicar un error. Con este cambio, la salida de stderr se sigue capturando en los objetos ErrorRecord, pero el entorno de ejecución ya no aplica $ErrorActionPreference si ErrorRecord proviene de un comando nativo.
Cambie el nombre -FromUnixTime a -UnixTimeSeconds activado Get-Date para permitir la entrada de hora de Unix (13084) (gracias). @aetos382!)

El parámetro -FromUnixTime se agregó durante la versión 7.1, versión preliminar 2. Se ha cambiado el nombre del parámetro para que encaje mejor con el tipo de datos. Este parámetro toma un valor entero que representa en segundos desde el 1 de enero de 1970, 0:00:00.

En este ejemplo se convierte una hora de UNIX (representada por el número de segundos desde 1970-01-01 0:00:00) en DateTime.
```
Get-Date -UnixTimeSeconds 1577836800

Wednesday, January 01, 2020 12:00:00 AM
```
Se ha permitido que el parámetro con nombre especificado explícitamente reemplace al mismo de la expansión mediante tabla hash (#13162).

Con este cambio, los parámetros con nombre de la expansión se mueven al final de la lista de parámetros para que se enlacen después de que se hayan enlazado todos los parámetros con nombre especificados explícitamente. El enlace de parámetros para funciones simples no produce ningún error cuando no se puede encontrar un parámetro con nombre especificado. Los parámetros con nombre desconocidos se enlazan con el parámetro $args de la función simple. Al mover la expansión al final de la lista de argumentos, se cambia el orden en el que aparecen los parámetros en $args.

Por ejemplo:
```
function SimpleTest {
    param(
        $Name,
        $Path
    )
    "Name: $Name; Path: $Path; Args: $args"
}
```
En el comportamiento anterior, MyPath no está enlazado con -Path porque es el tercer argumento de la lista de argumentos. ## Por lo tanto, termina rellenándose en "$args" junto con Blah = "World".
```
PS> $hash = @{ Name = "Hello"; Blah = "World" }
PS> SimpleTest @hash "MyPath"
Name: Hello; Path: ; Args: -Blah: World MyPath
```
Con este cambio, los argumentos de @hash se mueven al final de la lista de argumentos. MyPath se convierte en el primer argumento de la lista, así que está enlazado con -Path.
```
PS> SimpleTest @hash "MyPath"
Name: Hello; Path: MyPath; Args: -Blah: World
```
Haga que el parámetro -Qualifier switch no sea posicional para Split-Path (12960) (gracias) @yecril71pl!)
Resuelva el directorio de trabajo como ruta de acceso literal para Start-Process cuando no se especifique (11946) (gracias) @NoMoreFood!)
Haga que -OutFile el parámetro de los cmdlets web funcione como -LiteralPath (#11701) (gracias @iSazonov!)
Corrección del enlace de parámetros de cadena para BigInteger literales numéricos (#11634) (gracias) @vexx32!)
En Windows, Start-Process crea un entorno de proceso con todas las variables de entorno de la sesión actual, mediante -UseNewEnvironment crea un nuevo entorno de proceso predeterminado (10830) (gracias). @iSazonov!)
No se ajusta el resultado devuelto a PSObject al convertir ScriptBlock en un delegado (#10619).

Cuando un valor ScriptBlock se convierte en un tipo delegado que se debe usar en un contexto de C#, al ajustar el resultado en un valor PSObject se producen problemas innecesarios:
- Cuando el valor se convierte en el tipo devuelto delegado, el valor PSObject, básicamente, se desajusta. Por lo tanto, no se necesita PSObject.
- Cuando el tipo devuelto delegado es object, se ajusta en un valor PSObject, lo que dificulta trabajar en un código de C#.
Después de este cambio, el objeto devuelto es el subyacente.

Share via