Compartir a través de

Diferencias entre Windows PowerShell 5.1 y PowerShell 7.x

Windows PowerShell 5.1 se basa en .NET Framework v4.5. Con el lanzamiento de PowerShell 6.0, PowerShell se convirtió en un proyecto de código abierto basado en .NET Core 2.0. Pasar de .NET Framework a .NET Core permitió a PowerShell convertirse en una solución multiplataforma. PowerShell se ejecuta en Windows, macOS y Linux.

Hay algunas diferencias en el lenguaje de PowerShell entre Windows PowerShell y PowerShell. Las diferencias más importantes se encuentran en la disponibilidad y el comportamiento de los cmdlets de PowerShell entre las plataformas windows y las que no son windows y los cambios que se derivan de las diferencias entre .NET Framework y .NET Core.

En este artículo se resumen las diferencias significativas y los cambios importantes entre Windows PowerShell y la versión actual de PowerShell. Este resumen no incluye nuevas características ni cmdlets que se han agregado. Tampoco se describe lo que ha cambiado entre versiones. El objetivo de este artículo es presentar el estado actual de PowerShell y cómo es diferente de Windows PowerShell. Para obtener una explicación detallada de los cambios entre versiones y la adición de nuevas características, consulte los artículos Novedades de cada versión.

.NET Framework frente a .NET Core

PowerShell en Linux y macOS usa .NET Core, que es un subconjunto de .NET Framework completo en Microsoft Windows. Esto es importante porque PowerShell proporciona acceso directo a los tipos y métodos de marco subyacentes. Como resultado, es posible que los scripts que se ejecutan en Windows no se ejecuten en plataformas que no son de Windows debido a las diferencias en los marcos. Para obtener más información sobre los cambios en .NET Core, consulte Cambios importantes para la migración de .NET Framework a .NET Core.

Cada nueva versión de PowerShell se basa en una versión más reciente de .NET. Puede haber cambios importantes en .NET que afecten a PowerShell.

  • PowerShell 7.6: basado en .NET 10.0 (LTS)
  • PowerShell 7.5: basado en .NET 9.0
  • PowerShell 7.4: basado en .NET 8.0 (LTS)
  • PowerShell 7.3: basado en .NET 7.0
  • PowerShell 7.2: basado en .NET 6.0 (LTS)
  • PowerShell 7.1: basado en .NET 5.0
  • PowerShell 7.0: basado en .NET Core 3.1 (LTS)
  • PowerShell 6.2: basado en .NET Core 2.1
  • PowerShell 6.1: basado en .NET Core 2.1
  • PowerShell 6.0: basado en .NET Core 2.0

Con la llegada de .NET Standard 2.0, PowerShell puede cargar muchos módulos tradicionales de Windows PowerShell sin modificaciones. Además, PowerShell 7 incluye una característica de compatibilidad de Windows PowerShell que permite usar módulos de Windows PowerShell que todavía requieren el marco completo.

Para obtener más información, consulte:

Tenga en cuenta los cambios en el método de .NET

Aunque los cambios de método de .NET no son específicos de PowerShell, pueden afectar a los scripts, especialmente si se llama directamente a métodos de .NET. Además, puede haber nuevas sobrecargas para constructores. Esto puede tener un impacto en cómo se crean objetos mediante New-Object o el [type]::new() método .

Por ejemplo, .NET agregó sobrecargas al [System.String]::Split() método que no están disponibles en .NET Framework 4.5. En la lista siguiente se muestran las sobrecargas del Split() método disponible en Windows PowerShell 5.1:

PS> "".Split

OverloadDefinitions
-------------------
string[] Split(Params char[] separator)
string[] Split(char[] separator, int count)
string[] Split(char[] separator, System.StringSplitOptions options)
string[] Split(char[] separator, int count, System.StringSplitOptions options)
string[] Split(string[] separator, System.StringSplitOptions options)
string[] Split(string[] separator, int count, System.StringSplitOptions options)

En la lista siguiente se muestran las sobrecargas del Split() método disponible en PowerShell 7:

"".Split

OverloadDefinitions
-------------------
string[] Split(char separator, System.StringSplitOptions options)
string[] Split(char separator, int count, System.StringSplitOptions options)
string[] Split(Params char[] separator)
string[] Split(char[] separator, int count)
string[] Split(char[] separator, System.StringSplitOptions options)
string[] Split(char[] separator, int count, System.StringSplitOptions options)
string[] Split(string separator, System.StringSplitOptions options)
string[] Split(string separator, int count, System.StringSplitOptions options)
string[] Split(string[] separator, System.StringSplitOptions options)
string[] Split(string[] separator, int count, System.StringSplitOptions options)

En Windows PowerShell 5.1, podría pasar una matriz de caracteres (char[]) como string en el método Split(). El método divide la cadena de destino en cualquier aparición de un carácter de la matriz. El siguiente comando divide la cadena de destino en Windows PowerShell 5.1, pero no en PowerShell 7:

# PowerShell 7 example
"1111p2222q3333".Split('pq')

1111p2222q3333

Para enlazar a la sobrecarga correcta, debe escribir la cadena en una matriz de caracteres:

# PowerShell 7 example
"1111p2222q3333".Split([char[]]'pq')

1111
2222
3333

Los módulos ya no se incluyen con PowerShell

Por varias razones de compatibilidad, los siguientes módulos ya no se incluyen en PowerShell.

  • ISE
  • Microsoft.PowerShell.LocalAccounts
  • Microsoft.PowerShell.ODataUtils
  • Microsoft.PowerShell.Operation.Validation
  • PSScheduledJob
  • PSWorkflow
  • PSWorkflowUtility

Flujo de trabajo de PowerShell

El flujo de trabajo de PowerShell es una función en Windows PowerShell que se basa en Windows Workflow Foundation (WF) y permite la creación de libros de ejecución robustos para tareas de larga duración o paralelizadas.

Debido a la falta de compatibilidad con Windows Workflow Foundation en .NET Core, PowerShell Workflow se ha eliminado de PowerShell.

En el futuro, nos gustaría habilitar el paralelismo nativo o la simultaneidad en el lenguaje de PowerShell sin necesidad de flujo de trabajo de PowerShell.

Si es necesario usar puntos de control para reanudar un script después de reiniciar el sistema operativo, se recomienda usar el Programador de tareas para ejecutar un script en el inicio del sistema operativo, pero el script tendría que mantener su propio estado (como conservarlo en un archivo).

Cmdlets eliminados de PowerShell

Para los módulos que se incluyen en PowerShell, los siguientes cmdlets se quitaron de PowerShell por diversos motivos de compatibilidad o el uso de API no admitidas.

CimCmdlets

  • Export-BinaryMiLog

Microsoft.PowerShell.Core

  • Add-PSSnapin
  • Export-Console
  • Get-PSSnapin
  • Remove-PSSnapin
  • Resume-Job
  • Suspend-Job

Microsoft.PowerShell.Diagnostics

  • Export-Counter
  • Import-Counter

Microsoft.PowerShell.Management

  • Add-Computer
  • Checkpoint-Computer
  • Clear-EventLog
  • Complete-Transaction
  • Disable-ComputerRestore
  • Enable-ComputerRestore
  • Get-ComputerRestorePoint
  • Get-ControlPanelItem
  • Get-EventLog
  • Get-Transaction
  • Get-WmiObject
  • Invoke-WmiMethod
  • Limit-EventLog
  • New-EventLog
  • New-WebServiceProxy
  • Register-WmiEvent
  • Remove-Computer
  • Remove-EventLog
  • Remove-WmiObject
  • Reset-ComputerMachinePassword
  • Restore-Computer
  • Set-WmiInstance
  • Show-ControlPanelItem
  • Show-EventLog
  • Start-Transaction
  • Test-ComputerSecureChannel
  • Undo-Transaction
  • Use-Transaction
  • Write-EventLog

Microsoft.PowerShell.Utility

  • Convert-String
  • ConvertFrom-String

PSDesiredStateConfiguration

  • Disable-DscDebug
  • Enable-DscDebug
  • Get-DscConfiguration
  • Get-DscConfigurationStatus
  • Get-DscLocalConfigurationManager
  • Publish-DscConfiguration
  • Remove-DscConfigurationDocument
  • Restore-DscConfiguration
  • Set-DscLocalConfigurationManager
  • Start-DscConfiguration
  • Stop-DscConfiguration
  • Test-DscConfiguration
  • Update-DscConfiguration

Cmdlets de WMI v1

Los siguientes cmdlets de WMI v1 se quitaron de PowerShell:

  • Register-WmiEvent
  • Set-WmiInstance
  • Invoke-WmiMethod
  • Get-WmiObject
  • Remove-WmiObject

Los cmdlets del módulo CimCmdlets (también conocido como WMI v2) realizan la misma función y proporcionan una nueva funcionalidad y una sintaxis rediseñada.

New-WebServiceProxy Cmdlet eliminado

.NET Core no admite Windows Communication Framework, que proporciona servicios para usar el protocolo SOAP. Este cmdlet se quitó porque requiere SOAP.

*-Transaction Cmdlets eliminados

Estos cmdlets tenían un uso muy limitado. Se tomó la decisión de dejar de apoyarlos.

  • Complete-Transaction
  • Get-Transaction
  • Start-Transaction
  • Undo-Transaction
  • Use-Transaction

*-EventLog Cmdlets

Debido al uso de API no admitidas, los *-EventLog cmdlets se han quitado de PowerShell. Get-WinEvent y New-WinEvent están disponibles para obtener y crear eventos en Windows.

Cmdlets que usan Windows Presentation Framework (WPF)

.NET Core 3.1 agregó compatibilidad con WPF, por lo que la versión de PowerShell 7.0 restauró las siguientes características específicas de Windows:

  • El Show-Command cmdlet
  • El Out-GridView cmdlet
  • El parámetro ShowWindow de Get-Help

Cambios en la configuración de estado deseado (DSC) de PowerShell

Invoke-DscResource se restauró como una característica experimental en PowerShell 7.0.

A partir de PowerShell 7.2, el módulo PSDesiredStateConfiguration se ha quitado de PowerShell y se ha publicado en la Galería de PowerShell. Para obtener más información, consulte el anuncio en el blog del equipo de PowerShell.

Cambios en el archivo ejecutable de PowerShell

Cambio de nombre de powershell.exe a pwsh.exe

El nombre binario de PowerShell se ha cambiado de powershell(.exe) a pwsh(.exe). Este cambio proporciona una manera determinista para que los usuarios ejecuten PowerShell en máquinas y admitan instalaciones en paralelo de Windows PowerShell y PowerShell.

Cambios adicionales desde pwsh(.exe)powershell.exe:

  • Cambió el primer parámetro posicional de -Command a -File. Este cambio corrige el uso de #! (también llamado como shebang) en scripts PowerShell que se ejecutan desde shells que no son PowerShell en plataformas que no son Windows. También significa que puedes ejecutar comandos como pwsh foo.ps1 o pwsh fooScript sin especificar -File. Sin embargo, este cambio requiere que especifiques -c explícitamente o -Command al intentar ejecutar comandos como pwsh.exe -Command Get-Command.
  • pwsh acepta el conmutador -i (o -Interactive) para indicar un shell interactivo. Esto permite que PowerShell se use como shell predeterminado en plataformas Unix.
  • Eliminaron parámetros -ImportSystemModules y -PSConsoleFile de pwsh.exe.
  • Ayuda modificada pwsh -Version e integrada para pwsh.exe alinearse con otras herramientas nativas.
  • Mensajes de error de argumentos no válidos para -File y -Command y códigos de salida coherentes con los estándares de Unix
  • Añadido -WindowStyle un parámetro en Windows. Del mismo modo, las actualizaciones de las instalaciones basadas en paquetes en plataformas que no son Windows son actualizaciones locales.

El nombre abreviado también es coherente con la nomenclatura de shells en plataformas que no son de Windows.

Compatibilidad con la ejecución de un script de PowerShell con el parámetro bool

Anteriormente, el uso de pwsh.exe para ejecutar un script de PowerShell no proporcionaba -File ninguna manera de pasar $true/$false como valores de parámetro. Se añadió soporte para $true/$false valores como analizados a los parámetros. También se admiten los valores de switch.

Mejorada compatibilidad hacia atrás con Windows PowerShell

Para Windows, se añade un nuevo parámetro de cambio, UseWindowsPowerShell , a Import-Module. Este switch crea un módulo proxy en PowerShell 7 que utiliza un proceso local de PowerShell de Windows para ejecutar implícitamente cualquier cmdlet contenido en ese módulo. Para obtener más información, vea Import-Module.

Para más información sobre qué módulos Microsoft funcionan con PowerShell 7.0, consulte la Tabla de Compatibilidad de Módulos.

Soporte para Microsoft Update para Windows

PowerShell 7.2 ha agregado compatibilidad con Microsoft Update. Cuando activas esta función, recibirás las últimas actualizaciones de PowerShell 7 en tu flujo tradicional de gestión de Windows Update (WU), ya sea con Windows Update for Business, WSUS, SCCM o el diálogo interactivo WU en Configuración.

El paquete PowerShell 7.2 MSI incluye las siguientes opciones de línea de comandos:

  • USE_MU: esta propiedad tiene dos valores posibles:
    • 1 (por defecto) - Permite actualizar mediante Microsoft Update o WSUS
    • 0 - No participar en la actualización a través de Microsoft Update o WSUS
  • ENABLE_MU
    • 1 (por defecto) - Opta por usar Microsoft Update las Actualizaciones Automáticas o Windows Update
    • 0 - No opte por usar Microsoft Update las actualizaciones automáticas o Windows Update

Cambios en el motor

Compatibilidad con PowerShell como shell de Unix predeterminado

En Unix, es una convención que los shells acepten -i para un shell interactivo y muchas herramientas esperan este comportamiento (por ejemplo, script y cuando se establece PowerShell como el shell predeterminado) y se llama al shell con el conmutador -i. Este cambio está fallando que -i antes podía usarse como abreviatura para coincidir -InputFormat, que ahora debe ser -in.

Complementos personalizados

Los complementos de PowerShell son predecesores de los módulos de PowerShell que no tienen una adopción generalizada en la comunidad de PowerShell.

Debido a la complejidad de admitir complementos y su falta de uso en la comunidad, ya no se admiten complementos personalizados en PowerShell.

Marcas de características experimentales

PowerShell 6.2 habilitó soporte para características experimentales. Esto permite a los desarrolladores de PowerShell entregar nuevas características y recibir comentarios antes de que se complete el diseño. De esta manera, evitamos realizar cambios importantes a medida que evoluciona el diseño.

Úsalo Get-ExperimentalFeature para obtener una lista de características experimentales disponibles. Puedes activar o desactivar estas funciones con Enable-ExperimentalFeature y Disable-ExperimentalFeature.

Cargar el ensamblado desde la ruta base del módulo antes de intentar cargar desde la GAC

Anteriormente, cuando un módulo binario tiene el ensamblado de módulo en GAC, cargamos el ensamblado desde GAC antes de intentar cargarlo desde la ruta de acceso base del módulo.

Omitir la comprobación de elementos NULL para colecciones con un tipo de elemento de tipo valor

Para los Mandatory atributos del parámetro y ValidateNotNull de Y ValidateNotNullOrEmpty , salta la comprobación de elementos nulos si el tipo de elemento de la colección es tipo valor.

Conservar $? para ParenExpression, SubExpression y ArrayExpression

Esta solicitud de incorporación de cambios modifica la forma en que compilamos subtuberías (...), subexpresiones $(...) y expresiones de arreglo @() para que $? no sea automáticamente verdadero. En su lugar, el valor de $? depende del resultado de la canalización o de las instrucciones ejecutadas.

Arreglar $? para que no sea $false cuando el comando nativo escribe en stderr.

$? no se establece en $false cuando el comando nativo escribe en stderr. Es habitual que los comandos nativos escriban en stderr sin intentar indicar un error. $? se establece en $false solo cuando el comando nativo tiene un código de salida distinto de cero.

Hacer que $ErrorActionPreference no afecte la stderr salida de los comandos nativos

Es habitual que los comandos nativos escriban en stderr sin intentar indicar un error. Con este cambio, stderr la salida sigue capturándose en objetos ErrorRecord , pero el tiempo de ejecución ya no se aplica $ErrorActionPreference si el ErrorRecord proviene de un comando nativo.

Cambia $OutputEncoding para usar la codificación UTF-8 NoBOM en lugar de ASCII

La codificación anterior, ASCII (7 bits), produciría una alteración incorrecta de la salida en algunos casos. Al establecer UTF-8 NoBOM el valor predeterminado, se conserva la salida Unicode con una codificación compatible con la mayoría de las herramientas y los sistemas operativos.

Unificar cmdlets con parámetro -Encoding para ser de tipo System.Text.Encoding

El -Encoding valor Byte se ha quitado de los cmdlets del proveedor FileSystem. Un nuevo parámetro, -AsByteStream, se utiliza ahora para especificar que se requiere un flujo de bytes como entrada o que la salida es un flujo de bytes.

Cambio New-ModuleManifest de la codificación a UTF8NoBOM en plataformas que no son de Windows

Anteriormente, New-ModuleManifest creaba psd1 los manifiestos en UTF-16 con BOM, lo que creaba un problema para las herramientas de Linux. Este cambio de ruptura modifica la codificación de New-ModuleManifest para que sea UTF (sin BOM) en plataformas no Windows.

Quitar AllScope de la mayoría de los alias predeterminados

Para acelerar la creación del ámbito, AllScope se eliminó de la mayoría de los alias predeterminados. AllScope se dejó para algunos alias frecuentes donde la búsqueda era más rápida.

-Verbose y -Debug ya no invalidan $ErrorActionPreference

Anteriormente, si -Verbose se especificaba o -Debug se especificaba, anulaba el comportamiento de $ErrorActionPreference. Con este cambio, -Verbose y -Debug ya no afectan al comportamiento de $ErrorActionPreference.

Además, el -Debug parámetro establece $DebugPreference en Continue en lugar de Inquire.

Hacer que $PSCulture refleje de forma coherente los cambios culturales durante la sesión.

En Windows PowerShell, el valor de la cultura actual se almacena en caché, lo que puede permitir que el valor deje de estar sincronizado cuando la cultura se cambia después del inicio de la sesión. Este comportamiento de almacenamiento en caché se ha corregido en el núcleo de PowerShell.

Permitir que el parámetro con nombre especificado explícitamente reemplace al mismo proveniente de la propagación de parámetros desde una tabla hash.

Con este cambio, los parámetros con nombre del despliegue se mueven al final de la lista de parámetros para que se enlacen después de que todos los parámetros con nombre especificados explícitamente se hayan enlazado. El enlace de parámetros para funciones simples no produce un error cuando no se encuentra un parámetro con nombre especificado. Los parámetros desconocidos con nombre están ligados al $args parámetro de la función simple. Al mover el splatting al final de la lista de argumentos cambia el orden en 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 a -Path porque es el tercer argumento de la lista de argumentos. ## Así que acaba metido 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 trasladan al final de la lista de argumentos. MyPath se convierte en el primer argumento de la lista, por lo que está enlazado a -Path.

PS> SimpleTest @hash "MyPath"
Name: Hello; Path: MyPath; Args: -Blah: World

Cambios de idioma

Operador de fusión de NULL ??

El operador de fusión de NULL ?? devuelve el valor de su operando de la izquierda si no es NULL. De lo contrario, evalúa el operando de la derecha y devuelve su resultado. El operador ?? no evalúa su operando de la derecha si el operando de la izquierda se evalúa como no NULL.

$x = $null
$x ?? 100

100

En el ejemplo siguiente, el operando de la derecha no se evaluará.

[string] $todaysDate = '1/10/2020'
$todaysDate ?? (Get-Date).ToShortDateString()

1/10/2020

Operador de asignación de coalescencia NULL ??=

El operador de asignación de coalescencia NULL ??= asigna el valor del operando de la derecha a su operando de la izquierda solo si este último se evalúa como NULL. El operador ??= no evalúa su operando de la derecha si el operando de la izquierda se evalúa como no NULL.

$x = $null
$x ??= 100
$x

100

En el ejemplo siguiente, el operando de la derecha no se evaluará.

[string] $todaysDate = '1/10/2020'
$todaysDate ??= (Get-Date).ToShortDateString()

1/10/2020

Operadores condicionales NULL

Nota:

Esta característica se ha movido de experimental a estándar en PowerShell 7.1.

Un operador condicional NULL aplica un acceso a miembros, ?., o el acceso a elementos, ?[], operación a su operando solo si ese operando se evalúa como no NULL; de lo contrario, devuelve NULL.

Puesto que PowerShell permite que ? forme parte del nombre de la variable, se requiere la especificación formal del nombre de la variable para utilizar estos operadores. Por eso es necesario usar {} alrededor de los nombres de variables como ${a} o cuando ? forma parte del nombre ${a?}de la variable .

En el ejemplo siguiente, se devuelve el valor de PropName .

$a = @{ PropName = 100 }
${a}?.PropName

100

En el ejemplo siguiente se devolverá null, sin intentar acceder al nombre de miembro PropName.

$a = $null
${a}?.PropName

Del mismo modo, se devolverá el valor del elemento .

$a = 1..10
${a}?[0]

1

Y cuando el operando es NULL, no se obtiene acceso al elemento y se devuelve null.

$a = $null
${a}?[0]

Nota:

La sintaxis de nombre de variable de ${<name>} no debe confundirse con el $() operador de subexpresión. Para obtener más información, consulte la sección Nombre de variable de about_Variables.

Operador agregado & para la gestión de trabajos

Poner & al final de una tubería hace que la tubería se ejecute como un trabajo PowerShell. Cuando se encuentra en segundo plano una canalización, se devuelve un objeto de trabajo. Una vez que la tubería se ejecuta como un trabajo, se pueden usar todos los cmdlets estándar *-Job para gestionar el trabajo. Las variables (ignorando las variables específicas del proceso) usadas en la tubería se copian automáticamente al trabajo, así que Copy-Item $foo $bar & simplemente funcionan. El trabajo también se ejecuta en el directorio actual en lugar del directorio principal del usuario.

Nuevos métodos/propiedades en PSCustomObject

Hemos agregado nuevos métodos y propiedades a PSCustomObject. PSCustomObject ahora incluye una Count/Length propiedad como otros objetos.

$PSCustomObject = [pscustomobject]@{foo = 1}

$PSCustomObject.Length

1

$PSCustomObject.Count

1

Este trabajo también incluye ForEach métodos Where que te permiten operar y filtrar sobre PSCustomObject los artículos:

$PSCustomObject.ForEach({$_.foo + 1})

2

$PSCustomObject.Where({$_.foo -gt 0})

foo
---
  1

Conversiones de PSMethod a Delegate

Puede convertir un objeto PSMethod en un delegado. Esto te permite hacer cosas como pasar PSMethod[M]::DoubleStrLen como valor delegado a [M]::AggregateString:

class M {
    static [int] DoubleStrLen([string] $value) { return 2 * $value.Length }

    static [long] AggregateString([string[]] $values, [Func[string, int]] $selector) {
        [long] $res = 0
        foreach($s in $values){
            $res += $selector.Invoke($s)
        }
        return $res
    }
}

[M]::AggregateString((gci).Name, [M]::DoubleStrLen)

Comportamiento de comparación de cadenas cambiado en PowerShell 7.1

PowerShell 7.1 está construido sobre .NET 5.0, que introdujo el siguiente cambio de ruptura:

A partir de .NET 5.0, las comparaciones de cadenas invariantes a cultura ignoran los caracteres de control que no son imprimibles.

Por ejemplo, las siguientes dos cadenas se consideran idénticas:

# Escape sequence "`a" is Ctrl-G or [char]7
'Food' -eq "Foo`ad"

True

Cmdlets nuevos

Nuevo Get-Uptime cmdlet

El cmdlet Get-Uptime devuelve el tiempo transcurrido desde el último arranque del sistema operativo. El cmdlet se introdujo en PowerShell 6.0.

Nuevo Remove-Alias cmdlet

El cmdlet Remove-Alias quita un alias de la sesión actual de PowerShell. El cmdlet se introdujo en PowerShell 6.0.

Nuevo Remove-Service cmdlet

El cmdlet Remove-Service quita un servicio de Windows en el Registro y en la base de datos del servicio. El cmdlet Remove-Service se introdujo en PowerShell 6.0.

Nuevos cmdlets de Markdown

Markdown es un estándar para crear documentos de texto no cifrado legibles con formato básico que se puede representar en HTML.

Los siguientes cmdlets se agregaron en PowerShell 6.1:

  • ConvertFrom-Markdown : convierta el contenido de una cadena o un archivo en un objeto MarkdownInfo .
  • Get-MarkdownOption : devuelve los colores y estilos actuales que se usan para representar contenido de Markdown en la consola.
  • Set-MarkdownOption : establece los colores y estilos usados para representar el contenido de Markdown en la consola.
  • Show-Markdown : muestra el contenido de Markdown en la consola o como HTML

Nuevo Test-Json cmdlet

El cmdlet Test-Json comprueba si una cadena es un documento válido de notación de objetos JavaScript (JSON) y puede comprobar opcionalmente ese documento JSON con un esquema proporcionado.

Este cmdlet se introdujo en PowerShell 6.1

Nuevos cmdlets compatibles con características experimentales

Los siguientes cmdlets se agregaron en PowerShell 6.2 para admitir características experimentales.

Nuevo Join-String cmdlet

El cmdlet Join-String combina objetos de la canalización en una sola cadena. Este cmdlet se agregó en PowerShell 6.2.

Nueva vista VistaConcisa y cmdlet Get-Error

PowerShell 7.0 mejora la visualización de mensajes de error para mejorar la legibilidad de los errores interactivos y de script con una nueva vista predeterminada, ConcisoView. Las vistas son seleccionables por el usuario mediante la variable $ErrorViewde preferencia .

Con ConciseView, si un error no proviene de un error de script o analizador, entonces es un mensaje de error de una sola línea:

Get-ChildItem -Path C:\NotReal

Get-ChildItem: Can't find path 'C:\NotReal' because it doesn't exist

Si el error se produce durante la ejecución del script o es un error de análisis, PowerShell devuelve un mensaje de error de varias líneas que contiene el error, un puntero y un mensaje de error que muestra dónde se encuentra el error en esa línea. Si el terminal no soporta secuencias de escape de color ANSI (VT100), entonces los colores no se muestran.

La vista predeterminada en PowerShell 7 es ConciseView. La vista predeterminada anterior era NormalView y puedes seleccionarla configurando la variable $ErrorViewde preferencia.

$ErrorView = 'NormalView' # Sets the error view to NormalView
$ErrorView = 'ConciseView' # Sets the error view to ConciseView

Nota:

Se añade una nueva propiedad $Host.PrivateData para soportar el cambio del color de acento del mensaje de error.

El nuevo Get-Errorcmdlet proporciona una vista completa y detallada del error completamente calificado cuando sea necesario. Por defecto, el cmdlet muestra todos los detalles, incluidas las excepciones internas, del último error que ocurrió.

El Get-Error cmdlet admite entrada desde la tubería usando la variable $Errorincorporada . Get-Error muestra todos los errores de canalización.

$Error | Get-Error

El Get-Error cmdlet soporta el parámetro Newest , permitiéndote especificar cuántos errores de la sesión actual deseas que se muestren.

Get-Error -Newest 3 # Displays the lst three errors that occurred in the session

Para obtener más información, vea Get-Error.

Cambios de cmdlet

Ejecución paralela agregada a ForEach-Object

A partir de PowerShell 7.0, el ForEach-Object cmdlet , que recorre en iteración los elementos de una colección, ahora tiene paralelismo integrado con el nuevo parámetro Parallel .

Por defecto, los bloques de script paralelos usan el directorio de trabajo actual del llamador que inició las tareas paralelas.

Este ejemplo recupera 50.000 entradas de registro de 5 registros del sistema en una máquina local con Windows:

$logNames = 'Security','Application','System','Windows PowerShell','Microsoft-Windows-Store/Operational'

$logEntries = $logNames | ForEach-Object -Parallel {
    Get-WinEvent -LogName $_ -MaxEvents 10000
} -ThrottleLimit 5

$logEntries.Count

50000

El parámetro Paralelo especifica el bloque de script que se ejecuta en paralelo para cada nombre de registro de entrada.

El nuevo parámetro ThrottleLimit limita el número de bloques de script que se ejecutan en paralelo en un momento dado. El valor predeterminado es 5.

Usa la $_ variable para representar el objeto de entrada actual en el bloque de script. Use el Using: modificador de ámbito para pasar referencias de variables al bloque de script en ejecución.

Para obtener más información, vea ForEach-Object.

Revisa system32 módulos integrados compatibles en Windows

En la actualización de Windows 10 1809 y Windows Server 2019, hemos actualizado una serie de módulos de PowerShell integrados para marcarlos como compatibles con PowerShell.

Cuando Se inicia PowerShell, se incluye $windir\System32 automáticamente como parte de la PSModulePath variable de entorno. Sin embargo, solo expone módulos a Get-Module y Import-Module si está CompatiblePSEdition marcado como compatible con Core.

Puedes anular este comportamiento para mostrar todos los módulos usando el -SkipEditionCheck parámetro switch. También hemos añadido una PSEdition propiedad a la salida de la tabla.

-lp alias para todos los -LiteralPath parámetros

Hemos creado un alias -lp de parámetro estándar para todos los cmdlets de PowerShell integrados que tienen un -LiteralPath parámetro .

Corrija Get-Item -LiteralPath a*b si a*b realmente no existe para devolver un error

Antes, -LiteralPath dado que un comodín lo trataba igual que -Path si no encontraba archivos, salía silenciosamente. El comportamiento correcto debería ser literal -LiteralPath , así que si el archivo no existe, debería dar error. El cambio consiste en tratar los comodines usados como -Literal algo literal.

Establecer el directorio de trabajo en el directorio actual en Start-Job

El Start-Job cmdlet ahora usa el directorio actual como directorio de trabajo para el nuevo trabajo.

Eliminación -Protocol de *-Computer cmdlets

El -Protocol parámetro se quitó de los siguientes cmdlets:

  • Rename-Computer
  • Restart-Computer
  • Stop-Computer

DCOM ya no se admite para la comunicación remota. Los cmdlets solo son compatibles con la remoting de WSMAN.

Elimina -ComputerName de *-Service cmdlets

Para fomentar el uso consistente del PSRP, se eliminó el -ComputerName parámetro de *-Service los cmdlets. Use Invoke-Command para ejecutar los cmdlets en equipos remotos en su lugar.

Corrección Get-Content -Delimiter para no incluir el delimitador en las líneas devueltas

Anteriormente, la salida al usar Get-Content -Delimiter era inconsistente e incómoda porque requería un procesamiento adicional de los datos para eliminar el delimitador. Este cambio quita el delimitador en las líneas devueltas.

Cambios en Format-Hex

El -Raw parámetro ahora no hace nada. El Format-Hex cmdlet muestra una representación exacta de números que incluye todos los bytes correspondientes a su tipo. Esto es lo que hizo el -Raw parámetro antes de este cambio.

Corrección de errores tipográficos en el nombre de la propiedad Get-ComputerInfo

BiosSerialNumber se escribió mal y BiosSeralNumber se ha cambiado a la ortografía correcta.

Cambios en algoritmos hash disponibles

Se han quitado los siguientes algoritmos hash de .NET:

  • MACTripleDES
  • RIPEMD160

Este cambio afecta al Get-FileHash cmdlet .

Agregar validación en cmdlets donde pasar $null devuelve todos los objetos en lugar de un error

Pasar $null a cualquiera de los siguientes ahora genera un error:

  • Get-Credential -UserName
  • Get-Event -SourceIdentifier
  • Get-EventSubscriber -SourceIdentifier
  • Get-Help -Name
  • Get-PSBreakpoint -Script
  • Get-PSProvider -PSProvider
  • Get-PSSessionConfiguration -Name
  • Get-Runspace -Name
  • Get-RunspaceDebug -RunspaceName
  • Get-Service -Name
  • Get-TraceSource -Name
  • Get-Variable -Name

Agregar compatibilidad con el formato de archivo de registro extendido W3C en Import-Csv

Anteriormente, el Import-Csv cmdlet no se puede usar para importar directamente los archivos de registro en formato de registro extendido de W3C y se necesitaría una acción adicional. Con este cambio, se admite el formato de registro extendido W3C.

Import-Csv pstypenames se aplica tras la importación cuando la información de tipo está presente en el CSV

Anteriormente, los objetos exportados mediante Export-Csv con TypeInformation importados con ConvertFrom-Csv no conservaban la información de tipo. Este cambio añade la información del tipo al pstypenames miembro si está disponible desde el archivo CSV.

-NoTypeInformation es el valor predeterminado en Export-Csv

Anteriormente, el Export-Csv cmdlet generaría un comentario como primera línea que contiene el nombre de tipo del objeto. El cambio excluye la información de tipo de forma predeterminada porque la mayoría de las herramientas CSV no las entiende. Este cambio se realizó para abordar los comentarios de los clientes.

Úsalo -IncludeTypeInformation para conservar el comportamiento anterior.

Permitir que * se use en la ruta del registro para Remove-Item

Antes, -LiteralPath dado que un comodín lo trataba igual que -Path si no encontraba archivos, salía silenciosamente. El comportamiento correcto debería ser literal -LiteralPath , así que si el archivo no existe, debería dar error. El cambio consiste en tratar los comodines usados como -Literal algo literal.

Group-Object ahora ordena los grupos.

Como parte de la mejora de rendimiento, Group-Object ahora devuelve una lista ordenada de los grupos. Aunque no debe confiar en el orden, podría verse afectado por este cambio si quería el primer grupo. Decidimos que esta mejora del rendimiento valía la pena el cambio, ya que el impacto de depender del comportamiento anterior es bajo.

Desviación estándar en Measure-Object

La salida de Measure-Object ahora incluye una propiedad StandardDeviation.

Get-Process | Measure-Object -Property CPU -AllStats

Count             : 308
Average           : 31.3720576298701
Sum               : 9662.59375
Maximum           : 4416.046875
Minimum           :
StandardDeviation : 264.389544720926
Property          : CPU

Get-PfxCertificate -Password

Get-PfxCertificate ahora tiene el parámetro Password, que toma un SecureString. Esto le permite usarlo de forma no interactiva:

$certFile = '\\server\share\pwd-protected.pfx'
$certPass = Read-Host -AsSecureString -Prompt 'Enter the password for certificate: '

$certThumbPrint = (Get-PfxCertificate -FilePath $certFile -Password $certPass ).ThumbPrint

Eliminación de la more función

En el pasado, PowerShell incluía una función en Windows llamada more que envolvía more.com. Ahora se ha quitado esa función.

Además, la help función cambió para usarse more.com en Windows, o el buscapersonas por defecto del sistema especificado en $Env:PAGER plataformas que no son Windows.

cd DriveName: Ahora los usuarios vuelven al directorio de trabajo actual en ese disco

Anteriormente, usar Set-Location o cd para devolver a un PSDrive enviaba a los usuarios a la ubicación predeterminada de esa unidad. Los usuarios ahora se envían al último directorio de trabajo actual conocido para esa sesión.

cd - Retornos al directorio anterior

C:\Windows\System32> cd C:\
C:\> cd -
C:\Windows\System32>

O en Linux:

PS /etc> cd /usr/bin
PS /usr/bin> cd -
PS /etc>

Además, cd y cd -- cambiar a $HOME.

Update-Help como no administrativo

Por demanda popular, Update-Help ya no es necesario dirigirse como administrador. Update-Help Ahora por defecto guarda la ayuda en una carpeta con alcance de usuario.

Where-Object -Not

Con la adición del parámetro -Not a Where-Object, puede filtrar un objeto en la tubería para verificar la no existencia de una propiedad o un valor de propiedad que sea null o vacío.

Por ejemplo, este comando devuelve todos los servicios que no tienen ningún servicio dependiente definido:

Get-Service | Where-Object -Not DependentServices

Cambios en cmdlets web

La API .NET subyacente de los Web Cmdlets ha sido cambiada a System.Net.Http.HttpClient. Este cambio proporciona muchas ventajas. Sin embargo, este cambio, junto con la falta de interoperabilidad con Internet Explorer, ha provocado varios cambios de ruptura dentro Invoke-WebRequest de y Invoke-RestMethod.

  • Invoke-WebRequest ahora solo soporta análisis HTML básico. Invoke-WebRequest siempre devuelve un BasicHtmlWebResponseObject objeto. Las ParsedHtml propiedades y Forms han sido retiradas.
  • BasicHtmlWebResponseObject.Headers los valores ahora String[] son en lugar de String.
  • BasicHtmlWebResponseObject.BaseResponse ahora es un System.Net.Http.HttpResponseMessage objeto.
  • La Response propiedad de excepciones de Web Cmdlet ahora es un System.Net.Http.HttpResponseMessage objeto.
  • El análisis estricto de cabeceras RFC es ahora el valor predeterminado para el -Headers parámetro and -UserAgent . Esto puede evitarse con -SkipHeaderValidation.
  • file:// y ftp:// los esquemas URI ya no están soportados.
  • System.Net.ServicePointManager Ya no se respetan los escenarios.
  • Actualmente no hay ninguna autenticación basada en certificados disponible en macOS.
  • El uso de -Credential un URI por encima http:// de un URI resultará en un error. Usa un https:// URI o proporciona el -AllowUnencryptedAuthentication parámetro para suprimir el error.
  • -MaximumRedirection ahora produce un error de terminación cuando los intentos de redirección superan el límite proporcionado en lugar de devolver los resultados de la última redirección.
  • En PowerShell 6.2, se realizó un cambio en la codificación UTF-8 de forma predeterminada para las respuestas JSON. Cuando no se proporciona un conjunto de caracteres para una respuesta JSON, la codificación predeterminada debe ser UTF-8 por RFC 8259.
  • Codificación predeterminada establecida en UTF-8 para application-json respuestas
  • Se ha agregado el parámetro -SkipHeaderValidation para permitir encabezados Content-Type no compatibles con los estándares.
  • Se ha agregado el parámetro -Form para soportar una compatibilidad simplificada multipart/form-data.
  • Manejo compatible y que no distingue entre mayúsculas y minúsculas de las claves de relación
  • Se ha agregado el parámetro -Resume para los cmdlets web.

Invoke-RestMethod devuelve información útil cuando no se devuelve ningún dato.

Cuando una API devuelve simplemente null, Invoke-RestMethod se serializaba como la cadena "null" en lugar de $null. Este cambio fija la lógica en Invoke-RestMethod para serializar correctamente un literal JSON null válido de un solo valor como $null.

Los cmdlets web advierten cuando -Credential se envían a través de conexiones sin cifrar

Cuando se usa HTTP, el contenido que incluye contraseñas se envía como texto no cifrado. Este cambio es no permitirlo de forma predeterminada y devolver un error si se pasan las credenciales de forma no segura. Los usuarios pueden saltarse esto usando el -AllowUnencryptedAuthentication switch.

Hacer que el parámetro -OutFile en los cmdlets web funcione como -LiteralPath

A partir de PowerShell 7.1, el parámetro OutFile de los cmdlets web funciona como LiteralPath y no procesa caracteres comodín.

Cambios de API

Quitar AddTypeCommandBase clase

La AddTypeCommandBase clase fue retirada Add-Type para mejorar el rendimiento. Esta clase es usada solo por el cmdlet Add-Type y no debería afectar a los usuarios.

Eliminado VisualBasic como lenguaje soportado en Add-Type

Antes, podías compilar código de Visual Basic usando el Add-Type cmdlet. Visual Basic rara vez se usaba con Add-Type. Hemos quitado esta característica para reducir el tamaño de PowerShell.

Se ha quitado RunspaceConfiguration la compatibilidad

Anteriormente, al crear un espacio de ejecución de PowerShell mediante programación mediante la API, podría usar las clases heredadas RunspaceConfiguration o las más recientes InitialSessionState . Este cambio eliminó el soporte para RunspaceConfiguration y solo soporta InitialSessionState.

CommandInvocationIntrinsics.InvokeScript enlazar argumentos a $input en lugar de $args

Una posición incorrecta de un parámetro dio lugar a los argumentos pasados como entrada en lugar de como argumentos.

Quitar ClrVersion y BuildVersion propiedades de $PSVersionTable

La ClrVersion propiedad de $PSVersionTable no es útil con CoreCLR. Los usuarios finales no deben usar ese valor para determinar la compatibilidad.

La BuildVersion propiedad estaba vinculada a la versión de compilación de Windows, que no está disponible en plataformas que no son de Windows. Use la GitCommitId propiedad para recuperar la versión de compilación exacta de PowerShell.

Implementación del análisis de escape Unicode

`u#### o `u{####} se convierte al carácter Unicode correspondiente. Para obtener un literal `u, escape del backtick: ``u.

Problema de enlace de parámetros con ValueFromRemainingArguments en funciones de PS

ValueFromRemainingArguments ahora devuelve los valores como un array en lugar de un único valor que a su vez es un array.

Usos limpios de CommandTypes.Workflow y WorkflowInfoCleaned

Limpie el código relacionado con los usos de CommandTypes.Workflow y WorkflowInfo en System.Management.Automation.

Estos cambios importantes menores afectan principalmente al código del proveedor de ayuda.

  • Cambie los constructores públicos de WorkflowInfo a interno. Ya no se admite el workflow, por lo que tiene sentido no permitir que las personas creen instancias de Workflow.
  • Quite el tipo System.Management.Automation.DebugSource, ya que solo se usa para la depuración de flujo de trabajo.
  • Quite la sobrecarga de SetParent de la clase abstracta Debugger que solo se usa para la depuración de flujo de trabajo.
  • Elimine la misma sobrecarga de SetParent de la clase derivada RemotingJobDebugger.

No envolver el resultado devuelto en PSObject al convertir un ScriptBlock en un delegado.

Cuando a ScriptBlock se convierte en un tipo de delegado para usarse en el contexto de C#, envolver el resultado en a PSObject trae problemas innecesarios:

  • Cuando el valor se convierte al tipo de retorno de delegado, el PSObject esencialmente se desenrolla. Así que no PSObject es necesario.
  • Cuando el tipo de retorno de delegado es object, se envuelve en a PSObject , lo que dificulta trabajar con él en código C#.

Tras este cambio, el objeto devuelto es el objeto subyacente.

Apoyo remoto

La comunicación remota de PowerShell (PSRP) con WinRM no se admite para plataformas que no son de Windows. Puede usar la comunicación remota de PowerShell (PSRP) a través de WinRM desde Windows para conectarse a otras máquinas Windows. PowerShell también admite la comunicación remota a través de SSH en todas las plataformas (Windows, macOS y Linux). Para más información, consulte Comunicación remota de SSH en PowerShell.

PowerShell Direct para contenedores intenta usar pwsh primero

PowerShell Direct es una función de PowerShell y Hyper-V que permite conectarte a una Hyper-V VM o contenedor sin conectividad de red ni otros servicios de gestión remota.

En el pasado, PowerShell Direct se conecta mediante la instancia integrada de Windows PowerShell en el contenedor. Ahora, PowerShell Direct intenta primero conectarse usando cualquiera disponible pwsh.exe en la PATH variable de entorno. Si pwsh.exe no está disponible, PowerShell Direct vuelve a usar powershell.exe.

Enable-PSRemoting Ahora crea puntos finales remotos separados para las versiones de vista previa

Enable-PSRemoting Ahora crea dos configuraciones de sesión remota:

  • Una para la versión principal de PowerShell. Por ejemplo: PowerShell.6. Este punto de conexión que se puede confiar en las actualizaciones de versiones secundarias como la configuración de sesión de PowerShell 6 "en todo el sistema"
  • Una configuración de sesión específica de una versión, por ejemplo: PowerShell.6.1.0

Este comportamiento es útil si desea tener varias versiones de PowerShell 6 instaladas y accesibles en la misma máquina.

Además, las versiones previsuales de PowerShell ahora tienen sus propias configuraciones de sesión remota tras ejecutar el Enable-PSRemoting cmdlet:

C:\WINDOWS\system32> Enable-PSRemoting

La salida puede ser diferente si no ha configurado WinRM antes.

WinRM is already set up to receive requests on this computer.
WinRM is already set up for remote management on this computer.

A continuación, puede ver configuraciones de sesión de PowerShell independientes para las compilaciones preliminares y estables de PowerShell 6 y para cada versión específica.

Get-PSSessionConfiguration

Name          : PowerShell.6.2-preview.1
PSVersion     : 6.2
StartupScript :
RunAsUser     :
Permission    : NT AUTHORITY\INTERACTIVE AccessAllowed, BUILTIN\Administrators AccessAllowed, BUILTIN\Remote Management Users AccessAllowed

Name          : PowerShell.6-preview
PSVersion     : 6.2
StartupScript :
RunAsUser     :
Permission    : NT AUTHORITY\INTERACTIVE AccessAllowed, BUILTIN\Administrators AccessAllowed, BUILTIN\Remote Management Users AccessAllowed

Name          : powershell.6
PSVersion     : 6.1
StartupScript :
RunAsUser     :
Permission    : NT AUTHORITY\INTERACTIVE AccessAllowed, BUILTIN\Administrators AccessAllowed, BUILTIN\Remote Management Users AccessAllowed

Name          : powershell.6.1.0
PSVersion     : 6.1
StartupScript :
RunAsUser     :
Permission    : NT AUTHORITY\INTERACTIVE AccessAllowed, BUILTIN\Administrators AccessAllowed, BUILTIN\Remote Management Users AccessAllowed

user@host:port sintaxis soportada para SSH

Los clientes SSH suelen soportar una cadena de conexión en el formato user@host:port. Con la adición de SSH como protocolo para la comunicación remota de PowerShell, hemos agregado compatibilidad con este formato de cadena de conexión:

Enter-PSSession -HostName fooUser@ssh.contoso.com:2222

La telemetría solo se puede deshabilitar con una variable de entorno

PowerShell envía datos de telemetría básicos a Microsoft cuando se inicia. Los datos incluyen el nombre del sistema operativo, la versión del sistema operativo y la versión de PowerShell. Estos datos nos permiten comprender mejor los entornos en los que se usa PowerShell y nos permite priorizar las nuevas características y correcciones.

Para no participar en esta telemetría, establezca la variable de entorno POWERSHELL_TELEMETRY_OPTOUT en true, yeso 1. Ya no admitimos eliminar el archivo DELETE_ME_TO_DISABLE_CONSOLEHOST_TELEMETRY para desactivar la telemetría.

  • Last updated on