Partilhar via

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

O Windows PowerShell 5.1 foi criado sobre o .NET Framework v4.5. Com o lançamento do PowerShell 6.0, o PowerShell tornou-se um projeto de código aberto baseado no .NET Core 2.0. A mudança 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 na linguagem do PowerShell entre o Windows PowerShell e o PowerShell. As diferenças mais notáveis estão na disponibilidade e no comportamento dos cmdlets do PowerShell entre plataformas Windows e não Windows e nas alterações decorrentes das diferenças entre o .NET Framework e o .NET Core.

Este artigo resume as diferenças significativas e as alterações significativas entre o 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 do Windows PowerShell. Para obter uma discussão detalhada sobre as alterações entre 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 macOS usa o núcleo .NET, 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 no Windows podem não ser executados em plataformas que não sejam do Windows devido às diferenças nas estruturas. Para obter mais informações sobre alterações no .NET Core, consulte Alterações recentes para migração do .NET Framework para o .NET Core.

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

  • PowerShell 7.5 - Baseado no .NET 9.0
  • PowerShell 7.4 - Baseado no .NET 8.0
  • PowerShell 7.3 - Baseado no .NET 7.0
  • PowerShell 7.2 (LTS-current) - Baseado no .NET 6.0 (LTS-current)
  • PowerShell 7.1 - Baseado no .NET 5.0
  • PowerShell 7.0 (LTS) - Baseado no .NET Core 3.1 (LTS)
  • PowerShell 6.2 - Baseado no .NET Core 2.1
  • PowerShell 6.1 - Baseado no .NET Core 2.1
  • PowerShell 6.0 - Baseado no .NET Core 2.0

Com o advento do .NET Standard 2.0, o PowerShell pode carregar muitos módulos tradicionais do Windows PowerShell sem modificação. Além disso, o PowerShell 7 inclui um recurso de compatibilidade do Windows PowerShell que permite usar módulos do Windows PowerShell que ainda exigem a estrutura completa.

Para obter mais informações, veja:

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

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

Por exemplo, o .NET adicionou ao método [System.String]::Split() sobrecargas que não estão disponíveis no .NET Framework 4.5. A lista a seguir mostra as sobrecargas para o Split() método 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ê podia 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 vincular à sobrecarga correta, deves converter a cadeia de caracteres numa matriz de caracteres:

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

1111
2222
3333

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

Por vários motivos de compatibilidade, os módulos a seguir não estã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

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

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

No futuro, gostaríamos de habilitar paralelismo/simultaneidade nativos na linguagem PowerShell sem a necessidade do Fluxo de Trabalho do PowerShell.

Se houver 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 persisti-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 uma nova funcionalidade e uma sintaxe redesenhada.

New-WebServiceProxy cmdlet foi removido

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

*-Transaction cmdlets removidos

Esses cmdlets tinham uso muito limitado. Foi tomada a decisão de interromper 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 usam o Windows Presentation Framework (WPF)

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

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

Alterações na Configuração de Estado Desejado (DSC) do PowerShell

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 publicado na Galeria do PowerShell. Para obter mais informações, consulte o anúncio no blog da Equipe do PowerShell.

Alterações executáveis do PowerShell

O nome de powershell.exe foi mudado 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 máquinas e darem suporte a instalações lado a lado do Windows PowerShell e do PowerShell.

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

  • Alterado 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 a partir de shells que não são do PowerShell em plataformas que não são do Windows. Isso também significa que você pode executar comandos como pwsh foo.ps1 ou pwsh fooScript sem especificar -File. No entanto, essa alteração requer que você especifique -c explicitamente ou -Command ao tentar executar comandos como pwsh.exe -Command Get-Command.
  • pwsh suporta 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.
  • Removidos os parâmetros -ImportSystemModules e -PSConsoleFile de pwsh.exe.
  • Alterou pwsh -Version e ajuda integrada para pwsh.exe para alinhar com outras ferramentas nativas.
  • Mensagens de erro para argumentos inválidos em -File e -Command, e códigos de saída que são consistentes com os padrões Unix.
  • Adicionado o parâmetro -WindowStyle no Windows. Da mesma forma, as atualizações de instalações baseadas em pacotes em plataformas que não são do Windows são atualizações no local.

O nome abreviado também é consistente com a denominação de shells em plataformas não 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 fornecia nenhuma maneira de passar $true/$false como valores de parâmetro. Foi adicionado suporte para $true/$false como valores analisados aos parâmetros. Os valores de comutação também são suportados.

Compatibilidade melhorada com versões anteriores do Windows PowerShell

Para Windows, um novo parâmetro de opção UseWindowsPowerShell é adicionado ao Import-Module. Essa opção cria um módulo proxy no PowerShell 7 que usa um processo local do Windows PowerShell para executar implicitamente quaisquer cmdlets contidos nesse módulo. Para obter mais informações, consulte Import-Module.

Para obter mais informações sobre quais módulos da Microsoft funcionam com o PowerShell 7.0, consulte a Tabela de compatibilidade de módulos.

Suporte do Microsoft Update para Windows

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

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

  • USE_MU - Esta propriedade tem dois valores possíveis:
    • 1 (padrão) - Opta pela atualização por meio do Microsoft Update ou do WSUS
    • 0 - Não opte por atualizar através do Microsoft Update ou WSUS
  • ENABLE_MU
    • 1 (padrão) - Opta por usar o Microsoft Update, as Atualizações Automáticas ou o Windows Update
    • 0 - Não opte por usar o Microsoft Update, as Atualizações Automáticas ou o Windows Update

Mudanças de motor

Suporte 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 chama o shell com o -i switch. Esta alteração resulta em uma alteração significativa porque -i anteriormente podia ser usado como abreviação para corresponder a -InputFormat, o que agora precisa ser -in.

Snap-ins personalizados

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

Devido à complexidade do suporte a snap-ins e sua falta de uso na comunidade, não oferecemos mais suporte a 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 feedback antes que o design seja concluído. Desta 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 habilitar ou desabilitar esses recursos com Enable-ExperimentalFeature e Disable-ExperimentalFeature.

Carregue a montagem a partir do caminho base do módulo antes de tentar carregar a partir do GAC

Anteriormente, quando um módulo binário tinha o conjunto do módulo no GAC, carregávamos o conjunto do GAC antes de tentar carregá-lo a partir do caminho base do módulo.

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

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

Preservar $? para ParenExpression, SubExpression e ArrayExpression

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

Corrija $? para não ser $false quando o comando nativo escreve em stderr

$? não está definido como $false quando o comando nativo grava no stderr. É comum que comandos nativos escrevam 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.

Fazer $ErrorActionPreference não afetar a stderr saída de comandos nativos

É comum que os comandos nativos escrevam em stderr sem a intenção de indicar uma falha. Com esta alteração, a saída ainda é capturada em objetos ErrorRecord, mas o tempo de execução já não aplica $ErrorActionPreference se a ErrorRecord provier 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 preserva a saída Unicode com uma codificação suportada pela maioria das ferramentas e sistemas operacionais.

Unifique cmdlets com parâmetros -Encoding 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 a codificação para UTF8NoBOM em plataformas que não sejam Windows

Anteriormente, New-ModuleManifest criou psd1 manifestos em UTF-16 com BOM, criando problemas para as ferramentas Linux. Esta alteração de quebra altera a codificação de New-ModuleManifest para ser UTF (sem BOM) em plataformas nã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 aliases usados com frequência, onde a pesquisa era mais rápida.

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

Anteriormente, se -Verbose ou -Debug fosse especificado, ele substituía o comportamento do $ErrorActionPreference. Com esta mudança, -Verbose e -Debug deixam de afetar o comportamento de $ErrorActionPreference.

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

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

No Windows PowerShell, o valor da cultura atual é armazenado em cache, o que pode permitir que o valor fique fora de sincronia 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 explicitamente especificado substitua o mesmo do hashtable splatting

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

Por exemplo:

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

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

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

Com esta alteração, os argumentos de @hash são movidos para o final da lista de argumentos. MyPath torna-se o primeiro argumento na lista, por isso está vinculado a -Path.

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

Alterações linguísticas

Operador de coalescência nula ??

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

$x = $null
$x ?? 100

100

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

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

1/10/2020

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

O operador de atribuição de coalescência nula ??= atribui o valor de seu operando direito ao operando esquerdo somente se o operando esquerdo for avaliado como nulo. O operador ??= não avalia o operando à direita se o operando à esquerda for avaliado como não nulo.

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

100

No exemplo a seguir, o operando da 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 de experimental para mainstream no PowerShell 7.1.

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

Como o PowerShell permite que ? faça parte do nome da variável, a especificação formal do nome da variável é necessária para usar esses operadores. Portanto, é necessário usar {} em torno dos nomes de 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á null, 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 é null, o elemento não é acessado e null é 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 do about_Variables.

Adição de operador & para gestão de tarefas

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

Novos métodos/propriedades em PSCustomObject

Adicionamos novos métodos e propriedades ao 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 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 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 é baseado no .NET 5.0, que introduziu a seguinte alteração de rutura:

A partir do .NET 5.0, ignora-se, nas comparações de cadeias de caracteres invariantes de cultura, os caracteres de controle não imprimíveis.

Por exemplo, as duas cadeias de caracteres a seguir são consideradas idênticas:

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

True

Novos cmdlets

Novo cmdlet Get-Uptime

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 cmdlet Remove-Alias

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

Novo cmdlet Remove-Service

O cmdlet Remove-Service remove um serviço do 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 simples legíveis com formatação básica que podem ser renderizados em HTML.

Os seguintes cmdlets foram adicionados ao PowerShell 6.1:

  • ConvertFrom-Markdown - Converte 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 conteúdo de Markdown no console.
  • Set-MarkdownOption - Define as cores e estilos usados para renderizar o conteúdo Markdown no console.
  • Show-Markdown - Exibe o conteúdo do Markdown no console ou como HTML

Novo cmdlet Test-Json

O cmdlet Test-Json testa se uma cadeia de caracteres é um documento JSON (JavaScript Object Notation) válido e, opcionalmente, pode 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 oferecer suporte a Recursos Experimentais.

  • Desativar-FunçãoExperimental
  • Ativar-FuncionalidadeExperimental
  • Obter-RecursoExperimental

Novo cmdlet Join-String

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

Nova visualizaçã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 um novo modo de exibição padrão, ConciseView. As visualizações podem ser selecionadas pelo usuário por meio da variável $ErrorViewde preferência.

Com ConciseView, se um erro não for de um erro de script ou analisador, então passa a ser uma mensagem de erro numa única linha.

Get-ChildItem -Path C:\NotReal

Get-ChildItem: Cannot find path 'C:\NotReal' because it does not 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 cores ANSI (VT100), as cores não serão exibidas.

O modo de exibição padrão no PowerShell 7 é ConciseView. A visualização padrão anterior era NormalView e você pode selecioná-la definindo a variável $ErrorViewde preferência .

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

Observação

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

O novo Get-Errorcmdlet fornece uma visão completamente detalhada do erro totalmente especificado, quando desejado. Por padrão, o cmdlet exibe os detalhes completos, incluindo exceções internas, do último erro que ocorreu.

O cmdlet Get-Error oferece suporte à entrada através do pipeline usando a variável interna $Error. Get-Error Exibe todos os erros canalizados.

$Error | Get-Error

O Get-Error cmdlet oferece suporte ao parâmetro Newer , permitindo que você especifique quantos erros da sessão atual você deseja exibir.

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

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

Alterações no cmdlet

Execução paralela adicionada ao ForEach-Object

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

Por padrão, os blocos de script paralelo 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 executados em paralelo em um determinado momento. A predefinição é 5.

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

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

Verifique system32 se há módulos integrados compatíveis no Windows

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

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

Você pode substituir esse comportamento para mostrar todos os módulos usando o -SkipEditionCheck parâmetro switch. 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 o erro

Anteriormente, ao ser dado um wildcard, ele iria tratá-lo da mesma forma que -Path, e se o wildcard não encontrasse nenhum ficheiro, iria sair silenciosamente. O comportamento correto deve ser que -LiteralPath seja literal, portanto, se o arquivo não existir, deve ocorrer um erro. A alteração consiste em tratar as expressões curinga usadas com -Literal como literais.

Defina 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

Devido a problemas com a remoção RPC no CoreFX (particularmente em plataformas que não utilizam o Windows) e para garantir uma experiência de remoção consistente no PowerShell, o parâmetro -Protocol foi removido dos cmdlets \*-Computer. O DCOM não é mais suportado para comunicação remota. Os cmdlets a seguir oferecem suporte apenas à comunicação remota WSMAN:

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

Remover -ComputerName de *-Service cmdlets

Para incentivar o uso consistente do PSRP, o -ComputerName parâmetro foi removido dos *-Service cmdlets.

Corrigir Get-Content -Delimiter para não incluir o delimitador nas linhas devolvidas

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 nas linhas retornadas.

Alterações ao Format-Hex

O -Raw parâmetro é agora um "no-op" (na medida em que não faz nada). No futuro, todo o output é exibido com uma representação precisa dos números, que inclui todos os bytes de cada tipo. Isso é o que o -Raw parâmetro estava fazendo antes dessa mudança.

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

BiosSerialNumber foi escrito incorretamente como BiosSeralNumber e foi alterado para a ortografia correta.

Adicionar os cmdlets Get-StringHash e Get-FileHash

Esta alteração é que alguns algoritmos de hash não são suportados pelo CoreFX, portanto, eles não estão mais disponíveis:

  • MACTripleDES
  • RIPEMD160

Adicionar validação nos cmdlets em Get-* onde passar $null resulta em retorno de todos os objetos em vez de um 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

Adicione suporte para o W3C Extended Log File Format em Import-Csv

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

Import-Csv aplica pstypenames na importação quando a informação de tipo está presente 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 alteração adiciona as informações de tipo ao pstypenames membro, se disponível no ficheiro CSV.

-NoTypeInformation é o padrão em Export-Csv

Anteriormente, o Export-Csv cmdlet emitia um comentário como a primeira linha contendo 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 registo para Remove-Item

Anteriormente, -LiteralPath dado uma expressão curinga era tratado da mesma forma que -Path e caso não encontrasse arquivos, terminaria silenciosamente. O comportamento correto é que -LiteralPath seja literal, portanto, se o ficheiro não existir, deve gerar um erro. Alterar tratar os caracteres universais 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 não deva confiar na ordem, poderá ser prejudicado por esta mudança se quisesse o primeiro grupo. Decidimos que esta melhoria de desempenho valia a pena a mudança, uma vez que o impacto de ser dependente de comportamento anterior é baixo.

Desvio padrão na Measure-Object

A saída a partir de Measure-Object agora inclui uma StandardDeviation propriedade.

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 parâmetro Password, que aceita 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 incluía uma função para o Windows chamada more que envolvia more.com. Essa função foi agora removida.

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

cd DriveName: agora retorna os usuários para o diretório de trabalho atual nessa unidade

Anteriormente, usar Set-Location ou cd retornar a um PSDrive enviava os usuários para o local padrão dessa unidade. 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 -- mudam para $HOME.

Update-Help como não administrador

Por demanda popular, Update-Help não precisa mais ser executado como administrador. Update-Help Agora o padrão é salvar a Ajuda em uma pasta com escopo de usuário.

Where-Object -Not

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

Por exemplo, este 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 Web Cmdlets

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

  • Invoke-WebRequest agora suporta apenas análise HTML básica. 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 propriedade Response nas exceções do Web Cmdlet é agora um objeto System.Net.Http.HttpResponseMessage.
  • A análise estrita de cabeçalhos RFC agora é o padrão para os parâmetros -Headers e -UserAgent. Isso pode ser ignorado com -SkipHeaderValidation.
  • file:// e ftp:// os esquemas de URI não são mais suportados.
  • System.Net.ServicePointManager as configurações não são mais respeitadas.
  • Atualmente, não há autenticação baseada em certificado disponível no macOS.
  • O uso de -Credential sobre um URI http:// resultará em erro. Use um https:// URI ou forneça o -AllowUnencryptedAuthentication parâmetro para suprimir o erro.
  • -MaximumRedirection agora produz um erro de encerramento quando as tentativas de redirecionamento excedem o limite fornecido em vez de retornar os resultados do último redirecionamento.
  • No PowerShell 6.2, alterou-se a codificação padrão para UTF-8 para respostas JSON. Quando um charset 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
  • Parâmetro adicionado -SkipHeaderValidation para permitir Content-Type cabeçalhos que não são compatíveis com os padrões
  • Parâmetro adicionado -Form para suportar suporte simplificado multipart/form-data
  • Tratamento de chaves de relação compatível e sem diferenciação de maiúsculas e minúsculas
  • Adicionado o parâmetro -Resume nos cmdlets da 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 de caracteres "null" em vez de $null. Essa alteração corrige a lógica em Invoke-RestMethod para serializar corretamente um literal JSON null como um valor único válido em $null.

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

Ao usar HTTP, o conteúdo, incluindo senhas, é enviado como texto não criptografado. 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 ignorar isso usando o -AllowUnencryptedAuthentication switch.

Fazer com que o parâmetro -OutFile nos cmdlets da Web funcione como -LiteralPath

A partir do PowerShell 7.1, o parâmetro OutFile dos cmdlets da Web atua como LiteralPath e não processa caracteres curinga.

Alterações na 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.

Foi removido VisualBasic como um idioma suportado no Add-Type

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

Removido o suporte RunspaceConfiguration

Anteriormente, ao criar um espaço de execução do PowerShell programaticamente usando a API, você podia usar as classes herdadas RunspaceConfiguration ou mais recentes InitialSessionState . Esta alteração removeu o suporte para RunspaceConfiguration e apenas suporta InitialSessionState.

CommandInvocationIntrinsics.InvokeScript vincular argumentos a $input em vez de $args

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

Remover 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 BuildVersion propriedade foi vinculada à versão de compilação do Windows, que não está disponível em plataformas que não sejam Windows. Use a GitCommitId propriedade para recuperar a versão exata de compilação do PowerShell.

Implementar análise de escape Unicode

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

Problema de vinculação de parâmetros nas funções PS com ValueFromRemainingArguments

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

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 afetam principalmente o código do provedor de ajuda.

  • Mude os construtores públicos de WorkflowInfo para internos. Não suportamos mais fluxo de trabalho, então 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 Depurador, que é usada apenas para depuração de fluxo de trabalho.
  • Remova a mesma sobrecarga da classe derivada SetParentRemotingJobDebugger.

Não envolver o resultado de retorno em PSObject ao converter um ScriptBlock num delegado

Quando um ScriptBlock é convertido em um tipo de delegado para ser usado no contexto C#, envolver o resultado em um PSObject traz problemas desnecessários:

  • Quando o valor é convertido para o tipo de retorno delegado, o PSObject essencialmente é desempacotado. Portanto, o PSObject é desnecessário.
  • Quando o tipo de retorno de delegado é object, ele é encapsulado em um PSObject dificultando o trabalho no código C#.

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

Suporte Remoto

PowerShell Remoting (PSRP) usando WinRM em plataformas Unix requer NTLM/Negotiate ou Basic Auth através de HTTPS. O PSRP no macOS suporta apenas autenticação básica sobre HTTPS. A autenticação baseada em Kerberos não é suportada para plataformas que não sejam Windows.

O PowerShell também oferece suporte à comunicação remota do PowerShell (PSRP) sobre 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

O PowerShell Direct é um recurso do PowerShell e do 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 Windows PowerShell no contêiner. Agora, o PowerShell Direct tenta primeiro ligar-se utilizando qualquer pwsh.exe variável de ambiente disponível no PATH. Se pwsh.exe não estiver disponível, o PowerShell Direct voltará a usar powershell.exe.

Enable-PSRemoting agora cria pontos de extremidade remotos separados para versões de visualização

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

  • Um para a versão principal do PowerShell. Por exemplo, PowerShell.6. Este ponto de extremidade pode ser confiável em atualizações de versões secundárias como a configuração da sessão do PowerShell 6 para todo o sistema.
  • Uma configuração de sessão específica da 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 na mesma máquina.

Além disso, as versões de visualização do PowerShell agora obtêm suas próprias configurações de sessão remota depois de executar o Enable-PSRemoting cmdlet:

C:\WINDOWS\system32> Enable-PSRemoting

Sua saída pode 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 compilações estáveis e de visualização 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 suportam uma cadeia de conexão no formato user@host:port. Com a adição de SSH como um protocolo para comunicação remota do PowerShell, adicionamos suporte para este formato de cadeia de conexão:

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

A telemetria só pode ser desativada 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 onde o PowerShell é usado e nos permitem priorizar novos recursos e correções.

Para desativar essa telemetria, defina a variável de ambiente POWERSHELL_TELEMETRY_OPTOUT como true, yesou 1. Não suportamos mais a exclusão do arquivo DELETE_ME_TO_DISABLE_CONSOLEHOST_TELEMETRY para desativar a telemetria.