Diferenças entre Windows PowerShell 5.1 e PowerShell 7.x

Windows PowerShell 5.1 é criado com base no .NET Framework v4.5. Com o lançamento do PowerShell 6.0, o PowerShell tornou-se um projeto código aberto criado no .NET Core 2.0. A migração do .NET Framework para o .NET Core permitiu que o PowerShell se tornasse uma solução multiplataforma. O PowerShell é executado em Windows, macOS e Linux.

Há poucas diferenças no idioma do PowerShell entre Windows PowerShell e PowerShell. As diferenças mais importantes estão na disponibilidade e no comportamento dos cmdlets do PowerShell entre plataformas Windows e não Windows e as alterações que decorrem das diferenças entre o .NET Framework e o .NET Core.

Este artigo resume as diferenças significativas e as alterações significativas entre Windows PowerShell e a versão atual do PowerShell. Este resumo não inclui novos recursos ou cmdlets adicionados. Este artigo também não discute o que mudou entre as versões. O objetivo deste artigo é apresentar o estado atual do PowerShell e como isso é diferente de Windows PowerShell. Para obter uma discussão detalhada sobre as alterações entre as versões e a adição de novos recursos, consulte os artigos novidades para cada versão.

.NET Framework vs .NET Core

O PowerShell no Linux e no macOS usa o .NET Core, que é um subconjunto do .NET Framework completo no Microsoft Windows. Isso é significativo porque o PowerShell fornece acesso direto aos tipos e métodos de estrutura subjacentes. Como resultado, os scripts executados em Windows podem não ser executados em plataformas não Windows devido às diferenças nas estruturas. Para obter mais informações sobre alterações no .NET Core, consulte Breaking de alterações para migração do .NET Framework para .NET Core.

Cada nova versão do PowerShell é criada em uma versão mais recente do .NET. Podem haver alterações disruptivas em .NET que afetam o PowerShell.

  • PowerShell 7.6 – Baseado em .NET 10.0 (LTS)
  • PowerShell 7.5 – Baseado em .NET 9.0
  • PowerShell 7.4 – Baseado em .NET 8.0 (LTS)
  • PowerShell 7.3 – Criado em .NET 7.0
  • PowerShell 7.2 – Baseado em .NET 6.0 (LTS)
  • PowerShell 7.1 – Baseado em .NET 5.0
  • PowerShell 7.0 – Baseado em .NET Core 3.1 (LTS)
  • PowerShell 6.2 – Criado no .NET Core 2.1
  • PowerShell 6.1 – Baseado em .NET Core 2.1
  • PowerShell 6.0 – Criado no .NET Core 2.0

Com o advento do .NET Standard 2.0, o PowerShell pode carregar muitos módulos tradicionais do PowerShell Windows sem modificação. Além disso, o PowerShell 7 inclui um recurso de compatibilidade do Windows PowerShell que permite que você use módulos do Windows PowerShell que ainda exigem o .NET Framework completo.

Para obter mais informações, consulte:

Esteja ciente das alterações de método .NET

Embora as alterações de método do .NET não sejam específicas do PowerShell, elas podem afetar seus scripts, especialmente se você estiver chamando métodos do .NET diretamente. Além disso, pode haver novas sobrecargas para construtores. Isso pode ter um impacto na forma como você cria objetos usando New-Object ou o [type]::new() método.

Por exemplo, .NET adicionou sobrecargas ao método [System.String]::Split() que não estão disponíveis no .NET Framework 4.5. A lista a seguir mostra as sobrecargas para o método Split() disponível no 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)

A lista a seguir mostra as sobrecargas para o Split() método disponível no 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)

No Windows PowerShell 5.1, você pode passar uma matriz de caracteres (char[]) para o método Split() como um string. O método divide a cadeia de caracteres de destino em qualquer ocorrência de um caractere na matriz. O comando a seguir divide a cadeia de caracteres de destino no Windows PowerShell 5.1, mas não no PowerShell 7:

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

1111p2222q3333

Para associar à sobrecarga correta, você deve digitar a cadeia de caracteres em uma matriz de caracteres:

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

1111
2222
3333

Os módulos não são mais enviados com o PowerShell

Por vários motivos de compatibilidade, os módulos a seguir não são mais incluídos no PowerShell.

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

Fluxo de Trabalho do PowerShell

PowerShell Workflow é um recurso no Windows PowerShell que se baseia em Windows Workflow Foundation (WF) que permite a criação de runbooks robustos para tarefas de execução longa ou paralelizadas.

Devido à falta de suporte para Windows Workflow Foundation no .NET Core, removemos o fluxo de trabalho do PowerShell do PowerShell.

No futuro, gostaríamos de habilitar o paralelismo/simultaneidade nativo no idioma do PowerShell sem a necessidade de fluxo de trabalho do PowerShell.

Se houver a necessidade de usar pontos de verificação para retomar um script após a reinicialização do sistema operacional, recomendamos usar o Agendador de Tarefas para executar um script na inicialização do sistema operacional, mas o script precisará manter seu próprio estado (como mantê-lo em um arquivo).

Cmdlets removidos do PowerShell

Para os módulos incluídos no PowerShell, os cmdlets a seguir foram removidos do PowerShell por vários motivos de compatibilidade ou pelo uso de APIs sem suporte.

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 WMI v1

Os seguintes cmdlets WMI v1 foram removidos do PowerShell:

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

Os cmdlets do módulo CimCmdlets (também conhecido como WMI v2) executam a mesma função e fornecem novas funcionalidades e uma sintaxe revisada.

New-WebServiceProxy cmdlet removido

.NET Core não dá suporte ao Windows Communication Framework, que fornece serviços para usar o protocolo SOAP. Esse cmdlet foi removido porque requer SOAP.

*-Transaction CMDLETS removidos

Esses cmdlets tinham uso muito limitado. A decisão foi tomada para descontinuar o apoio a eles.

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

*-EventLog Cmdlets

Devido ao uso de APIs sem suporte, os *-EventLog cmdlets foram removidos do PowerShell. Get-WinEvent e New-WinEvent estão disponíveis para obter e criar eventos no Windows.

Cmdlets que utilizam o Windows Presentation Framework (WPF)

.NET Core 3.1 adicionou suporte para WPF, portanto, a versão do PowerShell 7.0 restaurou os seguintes recursos específicos Windows:

  • O Show-Command cmdlet
  • O Out-GridView cmdlet
  • O parâmetro ShowWindow de Get-Help

Alterações do PowerShell Desired State Configuration (DSC)

Invoke-DscResource foi restaurado como um recurso experimental no PowerShell 7.0.

A partir do PowerShell 7.2, o módulo PSDesiredStateConfiguration foi removido do PowerShell e foi publicado no Galeria do PowerShell. Para obter mais informações, consulte o comunicado no blog da Equipe do PowerShell.

Alterações executáveis do PowerShell

powershell.exe renomeado para pwsh.exe

O nome binário do PowerShell foi alterado de powershell(.exe) para pwsh(.exe). Essa alteração fornece uma maneira determinística para os usuários executarem o PowerShell em computadores e oferecerem suporte a instalações lado a lado do Windows PowerShell e PowerShell.

Alterações adicionais para pwsh(.exe) de powershell.exe:

  • Mudou o primeiro parâmetro posicional de -Command para -File. Essa alteração corrige o uso de #! (também conhecido como shebang) em scripts do PowerShell que estão sendo executados de shells que não sejam do PowerShell em plataformas não-Windows. Também significa que você pode executar comandos como pwsh foo.ps1 ou pwsh fooScript sem especificar -File. No entanto, essa mudança exige que você especifique -c explicitamente ou -Command ao tentar executar comandos como pwsh.exe -Command Get-Command.
  • pwsh aceita a opção -i (ou -Interactive) para indicar um shell interativo. Isso permite que o PowerShell seja usado como um shell padrão em plataformas Unix.
  • Foram removidos os parâmetros -ImportSystemModules e -PSConsoleFile de pwsh.exe.
  • Alterações realizadas em pwsh -Version e na ajuda integrada para pwsh.exe para alinhá-los com outras ferramentas nativas.
  • Mensagens de erro de argumento inválido para -File e -Command, e códigos de saída consistentes com os padrões do Unix.
  • Parâmetro -WindowStyle adicionado no Windows. Da mesma forma, nas plataformas não Windows, as atualizações de instalações baseadas em pacotes são atualizações in-place.

O nome abreviado também é consistente com a nomenclatura dos shells em plataformas que não sejam Windows.

Suporte à execução de um script do PowerShell com parâmetro bool

Anteriormente, usar pwsh.exe para executar um script do PowerShell usando -File não era possível passar $true/$false como valores de parâmetro. Foi adicionado suporte para $true/$false como valores analisados para parâmetros. Também há suporte para valores de alternância.

Compatibilidade com versões anteriores aprimoradas com Windows PowerShell

Para Windows, um novo parâmetro [switch]UseWindowsPowerShell é adicionado ao Import-Module. Esse parâmetro cria um módulo proxy no PowerShell 7 que usa um processo local do PowerShell Windows para executar implicitamente todos os cmdlets contidos nesse módulo. Para obter mais informações, consulte Import-Module .

Para obter mais informações sobre quais módulos Microsoft funcionam com o PowerShell 7.0, consulte o Module Compatibility Table.

Suporte para a atualização do Microsoft Windows

O PowerShell 7.2 adicionou suporte para Microsoft Update. Ao habilitar esse recurso, você irá receber as atualizações mais recentes do PowerShell 7 em seu fluxo de gerenciamento tradicional do WU (Windows Update), seja com Windows Update for Business, WSUS, SCCM ou a janela de diálogo interativa do WU em Configurações.

O pacote PowerShell 7.2 MSI inclui as seguintes opções de linha de comando:

  • USE_MU – essa propriedade tem dois valores possíveis:
    • 1 (padrão) – opta por atualizar por meio do Microsoft Update ou do WSUS
    • 0 – não opte por atualizar por meio de Microsoft Atualização ou WSUS
  • ENABLE_MU
    • 1 (padrão) – opta por usar o Microsoft Update para as Atualizações Automáticas ou o Windows Update
    • 0 – Não escolha usar o Microsoft Update, as Atualizações Automáticas ou o Windows Update

Alterações no motor

Dar suporte ao PowerShell como um shell unix padrão

No Unix, é uma convenção para shells aceitarem -i para um shell interativo, e muitas ferramentas esperam esse comportamento (script por exemplo, e ao definir o PowerShell como o shell padrão) e ativam o shell com a opção -i. Essa alteração é uma mudança crítica, pois -i antes podia ser usado como atalho para corresponder a -InputFormat, que agora precisa ser -in.

Snap-ins personalizados

Os snap-ins do PowerShell são um predecessor para módulos do PowerShell que não têm adoção generalizada na comunidade do PowerShell.

Devido à complexidade do suporte a snap-ins e à falta de uso na comunidade, não há mais suporte para snap-ins personalizados no PowerShell.

Sinalizadores de recursos experimentais

O PowerShell 6.2 habilitou o suporte para Recursos Experimentais. Isso permite que os desenvolvedores do PowerShell forneçam novos recursos e obtenham comentários antes que o design seja concluído. Dessa forma, evitamos fazer alterações significativas à medida que o design evolui.

Use Get-ExperimentalFeature para obter uma lista de recursos experimentais disponíveis. Você pode ativar ou desativar esses recursos com Enable-ExperimentalFeature e Disable-ExperimentalFeature.

Carregar o assembly do caminho base do módulo antes de tentar carregar do GAC

Anteriormente, quando um módulo binário tem o assembly do módulo no GAC, carregamos o assembly do GAC antes de tentar carregá-lo do caminho base do módulo.

Ignorar a verificação de elemento nulo para coleções com elemento de tipo valor

Para o parâmetro Mandatory e os atributos ValidateNotNull e ValidateNotNullOrEmpty, pule a verificação de nulo se o tipo de elemento da coleção for tipo valor.

Preservar $? para ParenExpression, SubExpression e ArrayExpression

Este PR altera a maneira como compilamos subpipelines (...), subexpressões $(...) e expressões @() de matriz para que $? não seja automaticamente verdadeiro. Em vez disso, o valor de $? depende do resultado do pipeline ou das instruções executadas.

Corrija $? para que não seja $false quando o comando nativo grava no stderr

$? não é configurado como $false quando o comando nativo grava em stderr. É comum que comandos nativos escrevam em stderr sem a intenção de indicar uma falha. $? é definido como $false somente quando o comando nativo tem um código de saída diferente de zero.

Evite que $ErrorActionPreference afete stderr a saída de comandos nativos

É comum que comandos nativos escrevam em stderr sem a intenção de indicar uma falha. Com essa mudança, stderr ainda é capturada a saída em objetos ErrorRecord, mas o runtime não se aplica mais $ErrorActionPreference se o ErrorRecord vier de um comando nativo.

Alterar $OutputEncoding para usar UTF-8 NoBOM codificação em vez de ASCII

A codificação anterior, ASCII (7 bits), resultaria em alteração incorreta da saída em alguns casos. Tornar UTF-8 NoBOM o padrão mantém a saída Unicode com uma codificação compatível com a maioria das ferramentas e sistemas operacionais.

Unificar cmdlets com parâmetro -Encoding para que seja do tipo System.Text.Encoding

O -Encoding valor Byte foi removido dos cmdlets do provedor FileSystem. Um novo parâmetro, -AsByteStream, agora é usado para especificar que um fluxo de bytes é necessário como entrada ou que a saída é um fluxo de bytes.

Alterar New-ModuleManifest codificação para UTF8NoBOM em plataformas não Windows

Anteriormente, New-ModuleManifest cria psd1 manifestos em UTF-16 com BOM, criando um problema para ferramentas do Linux. Essa mudança importante altera a codificação de New-ModuleManifest para ser UTF (sem BOM) em plataformas que não são Windows.

Remover AllScope da maioria dos aliases padrão

Para acelerar a criação do escopo, AllScope foi removido da maioria dos aliases padrão. AllScope foi deixado para alguns apelidos frequentemente usados onde a busca por estes apelidos era mais rápida.

-Verbose e -Debug não substitui mais $ErrorActionPreference

Anteriormente, se -Verbose ou -Debug fossem especificados, ele sobrepunha o comportamento de $ErrorActionPreference. Com essa mudança, -Verbose e -Debug não afeta mais o comportamento de $ErrorActionPreference.

Além disso, o -Debug parâmetro define $DebugPreference como Continuar em vez de Inquire.

Fazer com que $PSCulture reflita consistentemente as mudanças de cultura durante a sessão

No Windows PowerShell, o valor atual da cultura é armazenado em cache, o que pode permitir que o valor fique desatualizado quando a cultura é alterada após a inicialização da sessão. Esse comportamento de cache é corrigido no núcleo do PowerShell.

Permitir que o parâmetro nomeado especificado explicitamente prevaleça sobre o mesmo na aplicação de splatting da tabela hash.

Com essa alteração, os parâmetros nomeados da splatting são movidos para o final da lista de parâmetros para que sejam associados depois que todos os parâmetros nomeados explicitamente especificados forem associados. A associação de parâmetros para funções simples não gerará um erro quando um parâmetro nomeado especificado não puder ser encontrado. Parâmetros nomeados desconhecidos estão vinculados ao $args parâmetro da função simples. Mover o splatting para o final da lista de argumentos muda a ordem em que os parâmetros aparecem em $args.

Por exemplo:

function SimpleTest {
    param(
        $Name,
        $Path
    )
    "Name: $Name; Path: $Path; Args: $args"
}

No comportamento anterior, o MyPath não está associado a -Path porque é o terceiro argumento na lista de argumentos. ## Acaba sendo colocado em '$args' junto com Blah = "World"

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

Com essa mudança, os argumentos de @hash são movidos para o final da lista de argumentos. MyPath se torna o primeiro argumento da lista, portanto, ele é associado a -Path.

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

Alterações de idioma

Operador de coalescência de nulo ??

O operador de coalescência de nulo ?? retorna o valor do operando à esquerda caso não seja nulo. Caso contrário, ele avalia o operando do lado direito e retorna seu resultado. O operador ?? não avaliará o operando do lado direito se o operando esquerdo for avaliado como não nulo.

$x = $null
$x ?? 100

100

No exemplo a seguir, o operando do lado direito não será avaliado.

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

1/10/2020

Operador de atribuição de coalescência de nulo ??=

O operador de atribuição de avaliação de nulo ??= atribuirá o valor do operando do lado direito para o operando esquerdo somente se o operando esquerdo for avaliado como nulo. O operador ??= não avaliará o operando do lado direito se o operando esquerdo for avaliado como não nulo.

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

100

No exemplo a seguir, o operando à direita não será avaliado.

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

1/10/2020

Operadores condicionais nulos

Observação

Esse recurso foi movido do experimental para o mainstream no PowerShell 7.1.

Um operador condicional nulo aplicará uma operação de acesso de membro ?. ou de acesso de elemento ?[] ao operando somente se esse operando for avaliado como não nulo; caso contrário, ele retornará nulo.

Como o PowerShell permite que ? faça parte do nome da variável, é necessária uma especificação formal do nome da variável para usar esses operadores. Portanto, é necessário usar {} ao redor dos nomes das variáveis como ${a} ou quando ? faz parte do nome ${a?}da variável .

No exemplo a seguir, o valor de PropName é retornado.

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

100

O exemplo a seguir retornará nulo, sem tentar acessar o nome do membro PropName.

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

Da mesma forma, o valor do elemento será retornado.

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

1

E quando o operando é nulo, o elemento não é acessado e nulo é retornado.

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

Observação

A sintaxe do nome da variável ${<name>} não deve ser confundida com o operador de subexpressão $(). Para obter mais informações, consulte a seção Nome da variável de about_Variables.

Adicionado operador & para controle de tarefas

Colocar & no final de um pipeline faz com que ele seja executado como um trabalho PowerShell. Quando um pipeline é colocado em segundo plano, um objeto de trabalho é retornado. Uma vez que o pipeline estiver sendo executado como um trabalho, todos os cmdlets padrão *-Job podem ser usados para gerenciar o trabalho. Variáveis (ignorando variáveis específicas do processo) usadas no pipeline são copiadas automaticamente para o trabalho, então Copy-Item $foo $bar & simplesmente funciona. O trabalho também é executado no diretório atual em vez do diretório base do usuário.

Novos métodos/propriedades em PSCustomObject

Adicionamos novos métodos e propriedades a PSCustomObject. PSCustomObject agora inclui uma Count/Length propriedade como outros objetos.

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

$PSCustomObject.Length

1

$PSCustomObject.Count

1

Este trabalho também inclui ForEach e Where métodos que permitem operar e filtrar sobre os itens PSCustomObject.

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

2

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

foo
---
  1

Conversões de PSMethod para Delegate

Você pode converter um PSMethod em um delegado. Isso permite que você faça coisas como passar PSMethod[M]::DoubleStrLen como um valor de delegado para [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)

Comportamento de comparação de cadeia de caracteres alterado no PowerShell 7.1

O PowerShell 7.1 foi criado no .NET 5.0, que introduziu a seguinte alteração significativa:

A partir de .NET 5.0, as comparações de cadeias de caracteres culturalmente invariantes ignoram caracteres de controle não imprimíveis.

Por exemplo, as duas cadeias seguintes são consideradas idênticas:

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

True

Novos cmdlets

Novo Get-Uptime cmdlet

O cmdlet Get-Uptime retorna o tempo decorrido desde a última inicialização do sistema operacional. O cmdlet foi introduzido no PowerShell 6.0.

Novo Remove-Alias cmdlet

O cmdlet Remove-Alias remove um alias da sessão atual do PowerShell. O cmdlet foi introduzido no PowerShell 6.0.

Novo Remove-Service cmdlet

O cmdlet Remove-Service remove um serviço de Windows no registro e no banco de dados de serviço. O cmdlet Remove-Service foi introduzido no PowerShell 6.0.

Novos Cmdlets Markdown

Markdown é um padrão para criar documentos de texto sem formatação legíveis com formatação básica que pode ser renderizada em HTML.

Os seguintes cmdlets foram adicionados no PowerShell 6.1:

  • ConvertFrom-Markdown – converta o conteúdo de uma cadeia de caracteres ou um arquivo em um objeto MarkdownInfo.
  • Get-MarkdownOption - retorna as cores e estilos atuais usados para renderizar o conteúdo markdown no console.
  • Set-MarkdownOption – define as cores e os estilos usados para renderizar o conteúdo do Markdown no console.
  • Show-Markdown – exibe o conteúdo do Markdown no console ou como HTML

Novo Test-Json cmdlet

O cmdlet Test-Json testa se uma cadeia de caracteres é um documento JSON (JavaScript Object Notation) válido e pode, opcionalmente, verificar esse documento JSON em relação a um esquema fornecido.

Este cmdlet foi introduzido no PowerShell 6.1

Novos cmdlets para dar suporte a recursos experimentais

Os cmdlets a seguir foram adicionados no PowerShell 6.2 para dar suporte a recursos experimentais.

Novo Join-String cmdlet

O cmdlet Join-String combina objetos do pipeline em uma única cadeia de caracteres. Esse cmdlet foi adicionado ao PowerShell 6.2.

Nova exibição ConciseView e cmdlet Get-Error

O PowerShell 7.0 aprimora a exibição de mensagens de erro para melhorar a legibilidade de erros interativos e de script com uma nova exibição padrão, ConciseView. As visualizações são selecionáveis pelo usuário através da variável $ErrorViewde preferência .

Com o ConciseView, se um erro não for de script ou parser, então é uma mensagem de erro de uma linha:

Get-ChildItem -Path C:\NotReal

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

Se o erro ocorrer durante a execução do script ou for um erro de análise, o PowerShell retornará uma mensagem de erro de várias linhas que contém o erro, um ponteiro e uma mensagem de erro mostrando onde o erro está nessa linha. Se o terminal não suportar sequências de escape de cor ANSI (VT100), então as cores não são exibidas.

A visualização padrão no PowerShell 7 é o ConciseView. A visualização padrão anterior era NormalView e você pode selecionar isso definindo a variável $ErrorViewpreferencial.

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

Observação

Uma nova propriedade ErrorAccentColor é adicionada $Host.PrivateData para suportar a alteração da cor de destaque da mensagem de erro.

O novo Get-Errorcmdlet oferece uma visão completa e detalhada do erro qualificado quando necessário. Por padrão, o cmdlet exibe todos os detalhes, incluindo exceções internas, do último erro que ocorreu.

O Get-Error cmdlet suporta entrada do pipeline usando a variável embutida $Error. Get-Error exibe todos os erros encaminhados.

$Error | Get-Error

O Get-Error cmdlet suporta o parâmetro Newest , permitindo que você especifique quantos erros da sessão atual deseja que sejam exibidos.

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

Para obter mais informações, consulte Get-Error.

Alterações de cmdlet

Execução paralela adicionada a ForEach-Object

A partir do PowerShell 7.0, o ForEach-Object cmdlet, que itera itens em uma coleção, agora tem paralelismo interno com o novo parâmetro Parallel .

Por padrão, blocos de script paralelos usam o diretório de trabalho atual do chamador que iniciou as tarefas paralelas.

Este exemplo recupera 50.000 entradas de log de 5 logs do sistema em uma máquina Windows local:

$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

O parâmetro Parallel especifica o bloco de script que é executado em paralelo para cada nome de log de entrada.

O novo parâmetro ThrottleLimit limita o número de blocos de script rodando em paralelo em um dado momento. O padrão é 5.

Use a $_ variável para representar o objeto de entrada atual no bloco de script. Use o modificador de escopo Using: para passar referências de variável para o bloco de script em execução.

Para obter mais informações, consulte ForEach-Object.

Verifique system32 para módulos internos compatíveis com o Windows

Na Windows Server 2019 e atualização do Windows 10 1809, atualizamos vários módulos internos do PowerShell para marcá-los como compatíveis com o PowerShell.

Quando o PowerShell é iniciado, ele inclui $windir\System32 automaticamente como parte da PSModulePath variável de ambiente. No entanto, ele apenas expõe módulos a Get-Module e Import-Module se CompatiblePSEdition for marcado como compatível com Core.

Você pode substituir esse comportamento para mostrar todos os módulos usando o -SkipEditionCheck[switch] parâmetro. Também adicionamos uma PSEdition propriedade à saída da tabela.

-lp Alias para todos os -LiteralPath parâmetros

Criamos um alias -lp de parâmetro padrão para todos os cmdlets internos do PowerShell que têm um -LiteralPath parâmetro.

Corrigir Get-Item -LiteralPath a*b se a*b realmente não existir para retornar um erro

Antes, -LiteralPath tratava um curinga da mesma forma que -Path, e se o curinga não encontrasse arquivos, ele saía silenciosamente. O comportamento correto deve ser literal -LiteralPath , então se o arquivo não existir, ele deve apresentar erro. A mudança é tratar os curingas usados com -Literal como literais.

Definir o diretório de trabalho para o diretório atual em Start-Job

O Start-Job cmdlet agora usa o diretório atual como o diretório de trabalho para o novo trabalho.

Remover -Protocol de *-Computer cmdlets

O -Protocol parâmetro foi removido dos seguintes cmdlets:

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

O DCOM não tem mais suporte para comunicação remota. Os cmdlets só dão suporte à comunicação remota do WSMAN.

Remover -ComputerName de *-Service cmdlets

Para incentivar o uso consistente do PSRP, o -ComputerName parâmetro foi removido dos *-Service cmdlets. Use Invoke-Command para executar os cmdlets em computadores remotos.

Corrija Get-Content -Delimiter para não incluir o delimitador nas linhas retornadas.

Anteriormente, a saída durante o uso Get-Content -Delimiter era inconsistente e inconveniente, pois exigia processamento adicional dos dados para remover o delimitador. Essa alteração remove o delimitador em linhas retornadas.

Alterações para Format-Hex

O -Raw parâmetro agora não faz nada. O Format-Hex cmdlet exibe uma representação verdadeira de números que inclui todos os bytes de seu tipo. Isso é o que o -Raw parâmetro fez antes dessa alteração.

Correção de erro de digitação no nome da propriedade Get-ComputerInfo

BiosSerialNumber foi escrito incorretamente e BiosSeralNumber foi alterado para a grafia correta.

Alterações nos algoritmos de hash disponíveis

Os seguintes algoritmos de hash foram removidos do .NET:

  • MACTripleDES
  • RIPEMD160

Essa alteração afeta o Get-FileHash cmdlet.

Adicionar validação em Get-* cmdlets em que passar $null retorna todos os objetos em vez de erro

Passar $null para qualquer um dos seguintes agora gera um erro:

  • 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

Adicionar suporte para o formato de arquivo de log estendido W3C em Import-Csv

Anteriormente, o Import-Csv cmdlet não pode ser usado para importar diretamente os arquivos de log no formato de log estendido W3C e uma ação adicional seria necessária. Com essa alteração, há suporte para o formato de log estendido W3C.

Import-Csv pstypenames aplica-se após a importação quando as informações de tipo estão presentes no CSV

Anteriormente, os objetos exportados usando Export-Csv com TypeInformation importados com ConvertFrom-Csv não estavam retendo as informações de tipo. Essa mudança adiciona a informação do tipo ao pstypenames membro, se disponível no arquivo CSV.

-NoTypeInformation é o padrão em Export-Csv

Anteriormente, o Export-Csv cmdlet gerava um comentário como a primeira linha que contém o nome do tipo do objeto. A alteração exclui as informações de tipo por padrão porque elas não são compreendidas pela maioria das ferramentas CSV. Essa alteração foi feita para atender aos comentários dos clientes.

Use -IncludeTypeInformation para manter o comportamento anterior.

Permitir que * seja usado no caminho do registro para Remove-Item

Antes, -LiteralPath dado um curinga seria tratado da mesma forma que -Path e, se o curinga não encontrasse arquivos, ele encerrava silenciosamente. O comportamento correto deve ser literal -LiteralPath , então se o arquivo não existir, ele deve apresentar erro. A mudança é tratar os curingas usados com -Literal como literais.

Group-Object agora classifica os grupos

Como parte da melhoria de desempenho, Group-Object agora retorna uma lista ordenada dos grupos. Embora você não deva confiar na ordem, se quisesse o primeiro grupo, poderia ser prejudicado por essa alteração. Decidimos que essa melhoria de desempenho valia a pena, pois o impacto de depender do comportamento anterior é baixo.

Desvio padrão em Measure-Object

Agora, a saída de Measure-Object inclui a propriedade 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 agora tem o Password parâmetro, que usa um SecureString. Isso permite que você o use de forma não interativa:

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

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

Remoção da more função

No passado, o PowerShell enviava uma função em Windows chamada more que encapsulava more.com. Essa função foi removida.

Além disso, a função help foi alterada para usar more.com no Windows ou o pager padrão do sistema especificado por $Env:PAGER em plataformas não Windows.

cd DriveName: Agora retorna os usuários ao diretório funcional atual nesse drive

Anteriormente, usar Set-Location ou cd para retornar a um PSDrive enviava os usuários para o local padrão daquele disco. Os usuários agora são enviados para o último diretório de trabalho atual conhecido para essa sessão.

cd - retorna ao diretório anterior

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

Ou no Linux:

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

Além disso, cd e cd -- mudar para $HOME.

Update-Help como não-administrativo

Por demanda popular, Update-Help não precisa mais ser administrado como administrador. Update-Help Agora por padrão, salva a ajuda em uma pasta com escopo do usuário.

Where-Object -Not

Com a adição do parâmetro -Not para Where-Object, pode filtrar um objeto no pipeline para verificar a inexistência de uma propriedade ou um valor de propriedade nulo/vazio.

Por exemplo, esse comando retorna todos os serviços que não têm nenhum serviço dependente definido:

Get-Service | Where-Object -Not DependentServices

Alterações nos cmdlets da Web

A API de .NET subjacente dos Cmdlets Web foi alterada para System.Net.Http.HttpClient. Essa alteração oferece muitos benefícios. No entanto, essa alteração juntamente com a falta de interoperabilidade com Internet Explorer resultaram em várias alterações significativas em Invoke-WebRequest e Invoke-RestMethod.

  • Invoke-WebRequest agora suporta apenas análise sintática básica em HTML. Invoke-WebRequest sempre retorna um BasicHtmlWebResponseObject objeto. As ParsedHtml propriedades e Forms foram removidas.
  • BasicHtmlWebResponseObject.Headers os valores são agora String[] em vez de String.
  • BasicHtmlWebResponseObject.BaseResponse agora é um System.Net.Http.HttpResponseMessage objeto.
  • A Response propriedade sobre exceções Web Cmdlet agora é um System.Net.Http.HttpResponseMessage objeto.
  • A análise rigorosa de cabeçalhos RFC agora é padrão para os parâmetros -Headers e -UserAgent. Isso pode ser contornado com -SkipHeaderValidation.
  • file:// e ftp:// esquemas URI não são mais suportados.
  • System.Net.ServicePointManager As configurações não são mais respeitadas.
  • No momento, não há autenticação baseada em certificado disponível no macOS.
  • O uso de -Credential sobre um http:// URI resultará em um erro. Use um https:// URI ou forneça o -AllowUnencryptedAuthentication parâmetro para suprimir o erro.
  • -MaximumRedirection agora produz um erro de término quando tentativas de redirecionamento excedem o limite fornecido, em vez de retornar os resultados do último redirecionamento.
  • No PowerShell 6.2, foi feita uma alteração para codificação UTF-8 padrão para respostas JSON. Quando um conjunto de caracteres não é fornecido para uma resposta JSON, a codificação padrão deve ser UTF-8 por RFC 8259.
  • Codificação padrão definida como UTF-8 para application-json respostas
  • Adicionado parâmetro -SkipHeaderValidation para permitir cabeçalhos Content-Type que não estão em conformidade com os padrões.
  • Parâmetro adicionado -Form para dar suporte ao suporte simplificado multipart/form-data
  • Tratamento compatível e sem diferenciação de maiúsculas de minúsculas de chaves de relação
  • Parâmetro adicionado -Resume para cmdlets web

Invoke-RestMethod retorna informações úteis quando nenhum dado é retornado

Quando uma API retorna apenas null, Invoke-RestMethod estava serializando isso como a cadeia "null" de caracteres em vez de $null. Essa mudança corrige a lógica em Invoke-RestMethod para serializar corretamente um literal JSON de valor único válido como $null.

Cmdlets da Web avisam quando -Credential é enviado por conexões não criptografadas

Ao usar HTTP, o conteúdo que inclui senhas é enviado como texto sem formatação. Essa alteração é para não permitir isso por padrão e retornar um erro se as credenciais estiverem sendo passadas de forma insegura. Os usuários podem contornar isso usando o -AllowUnencryptedAuthentication switch.

Fazer com que o parâmetro -OutFile em cmdlets da web funcione como -LiteralPath

A partir do PowerShell 7.1, o parâmetro OutFile dos cmdlets web funciona como LiteralPath e não processa curingas.

Alterações da API

Remover AddTypeCommandBase classe

A classe AddTypeCommandBase foi removida de Add-Type para melhorar o desempenho. Essa classe é usada apenas pelo Add-Type cmdlet e não deve afetar os usuários.

Removido VisualBasic como idioma suportado em Add-Type

No passado, você poderia compilar Visual Basic código usando o cmdlet Add-Type. Visual Basic raramente era usado com Add-Type. Removemos esse recurso para reduzir o tamanho do PowerShell.

RunspaceConfiguration Suporte removido

Anteriormente, ao criar um runspace do PowerShell programaticamente usando a API, você poderia usar as classes herdadas RunspaceConfiguration ou mais recentes InitialSessionState . Essa mudança removeu o suporte para RunspaceConfiguration e suporta apenas InitialSessionState.

CommandInvocationIntrinsics.InvokeScript associar argumentos ao $input invés de $args

Uma posição incorreta de um parâmetro resultou no args passado como entrada em vez de como args.

Remova ClrVersion e BuildVersion propriedades de $PSVersionTable

A ClrVersion propriedade de $PSVersionTable não é útil com CoreCLR. Os usuários finais não devem usar esse valor para determinar a compatibilidade.

A propriedade BuildVersion estava vinculada à versão de build Windows, que não está disponível em plataformas não Windows. Use a GitCommitId propriedade para recuperar a versão de build exata do PowerShell.

Implementar a análise de sequências de escape Unicode

`u#### ou `u{####} é convertido para o caractere Unicode correspondente. Para produzir um literal `u, escape do backtick: ``u.

Problema de associação de parâmetro nas funções PS ValueFromRemainingArguments

ValueFromRemainingArguments agora retorna os valores como um array em vez de um único valor que por si só é um array.

Limpeza dos usos de CommandTypes.Workflow e WorkflowInfoCleaned

Limpe o código relacionado aos usos de CommandTypes.Workflow e WorkflowInfo em System.Management.Automation.

Essas pequenas alterações interruptivas afetam principalmente o código do fornecedor de ajuda.

  • Altere os construtores públicos de WorkflowInfo para internos. Não damos mais suporte ao fluxo de trabalho, portanto, faz sentido não permitir que as pessoas criem Workflow instâncias.
  • Remova o tipo System.Management.Automation.DebugSource , pois ele é usado apenas para depuração de fluxo de trabalho.
  • Remova a sobrecarga de SetParent da classe abstrata Debugger que é usada apenas para a depuração de fluxos de trabalho.
  • Remova a mesma sobrecarga da SetParent classe derivada RemotingJobDebugger.

Não encapsule o resultado do retorno em PSObject ao converter um ScriptBlock em um delegado

Quando a ScriptBlock é convertida para um tipo delegado para uso no contexto de C#, envolver o resultado em um PSObject acarreta problemas desnecessários.

  • Quando o valor é convertido para o tipo de retorno de delegate, o PSObject é essencialmente desempacotado. Então isso PSObject não é necessário.
  • Quando o tipo de retorno do delegado é object, ele é envolvido em um PSObject, dificultando o trabalho com o código C#.

Após essa alteração, o objeto retornado é o objeto subjacente.

Suporte remoto

O PowerShell Remoting (PSRP) usando o WinRM não tem suporte para plataformas não-Windows. Você pode usar o PowerShell Remoting (PSRP) usando o WinRM do Windows para se conectar a outros computadores Windows. O PowerShell também dá suporte à comunicação remota por SSH em todas as plataformas (Windows, macOS e Linux). Para obter mais informações, consulte SSH Remoting no PowerShell.

O PowerShell Direct for Containers tenta usar pwsh primeiro

PowerShell Direct é um recurso do PowerShell e Hyper-V que permite que você se conecte a uma VM ou Contêiner Hyper-V sem conectividade de rede ou outros serviços de gerenciamento remoto.

No passado, o PowerShell Direct se conectava usando a instância interna do PowerShell Windows no Contêiner. Agora, o PowerShell Direct tenta se conectar primeiro usando qualquer pwsh.exe disponível na variável de ambiente PATH. Se pwsh.exe não estiver disponível, o PowerShell Direct volta a usar powershell.exe.

Enable-PSRemoting Agora cria endpoints remotos separados para versões pré-visualizadas

Enable-PSRemoting Agora, cria duas configurações de sessão remota:

  • Uma para a versão principal do PowerShell. Por exemplo, PowerShell.6. Este endpoint pode ser confiável em atualizações de versão menores como a configuração de sessão no "sistema inteiro" do PowerShell 6.
  • Uma configuração de sessão específica para cada versão, por exemplo: PowerShell.6.1.0

Esse comportamento é útil se você quiser ter várias versões do PowerShell 6 instaladas e acessíveis no mesmo computador.

Além disso, versões pré-visualizadas do PowerShell agora recebem suas próprias configurações de sessão remota após executarem o Enable-PSRemoting cmdlet:

C:\WINDOWS\system32> Enable-PSRemoting

Sua saída poderá ser diferente se você não tiver configurado o WinRM antes.

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

Em seguida, você pode ver configurações de sessão separadas do PowerShell para as versões prévias e estáveis do PowerShell 6 e para cada versão 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 sintaxe suportada para SSH

Os clientes SSH normalmente dão suporte a um cadeia de conexão no formato user@host:port. Com a adição do SSH como um protocolo para comunicação remota do PowerShell, adicionamos suporte para esse formato de cadeia de conexão:

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

A telemetria só pode ser desabilitada com uma variável de ambiente

O PowerShell envia dados básicos de telemetria para a Microsoft quando é iniciado. Os dados incluem o nome do sistema operacional, a versão do sistema operacional e a versão do PowerShell. Esses dados nos permitem entender melhor os ambientes em que o PowerShell é usado e nos permite priorizar novos recursos e correções.

Para recusar essa telemetria, defina a variável de ambiente POWERSHELL_TELEMETRY_OPTOUT para true, yes ou 1. Não suportamos mais a exclusão do arquivo DELETE_ME_TO_DISABLE_CONSOLEHOST_TELEMETRY para desabilitar a telemetria.

  • Last updated on