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 que foram 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.

• O que há de novo no PowerShell 7.5
• O que há de novo no PowerShell 7.4
• O que há de novo no PowerShell 7.3
• O que há de novo no PowerShell 7.2
• O que há de novo no PowerShell 7.1
• O que há de novo no PowerShell 7.0
• O que há de novo no PowerShell 6.x

.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:

• about_Windows_PowerShell_Compatibility
• Compatibilidade do módulo PowerShell 7

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 [System.String]::Split() .NET adicionou sobrecargas ao método 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ê pode passar uma matriz de caracteres (char[]) para o Split() método como um stringarquivo . 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, 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 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 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 a pwsh(.exe) partir 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 aceita a -i opção (ou -Interactive) para indicar um shell interativo. Isso permite que o PowerShell seja usado como um shell padrão em plataformas Unix.
• Parâmetros -ImportSystemModules removidos e -PSConsoleFile de pwsh.exe.
• Ajuda alterada pwsh -version e integrada para pwsh.exe alinhamento com outras ferramentas nativas.
• Mensagens de erro de argumento inválidas para -File e -Command códigos de saída consistentes com os padrões Unix
• Adicionado -WindowStyle parâmetro 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 in-loco.

O nome abreviado também é consistente com a nomeaçã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 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 mudança está quebrando em que -i anteriormente poderia ser usado como mão curta para combinar -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 tem o conjunto do módulo no GAC, nós carregamos 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 matriz para que $? isso não seja automaticamente verdadeiro. Em vez disso, o valor de $? depende do resultado do pipeline ou das instruções executadas.

Correção $? para não ser $false quando o comando nativo grava em stderr

$? não está definido como $false quando o comando nativo grava no stderr. É comum que comandos nativos gravem 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 comandos nativos gravem stderr sem a intenção de indicar uma falha. Com essa alteração, stderr a saída ainda é capturada em objetos ErrorRecord , mas o tempo de execução não se aplica $ErrorActionPreference mais 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 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 do sistema de arquivos. 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 cria psd1 manifestos em UTF-16 com BOM, criando um problema 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 deixar de afetar o comportamento da $ErrorActionPreference.

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

Faça $PSCulture refletir consistentemente as mudanças de cultura na sessão

No Windows PowerShell, o valor da cultura atual é armazenado em cache, o que pode permitir que o valor fique fora de sincronia com 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 porque -Path é 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 essa alteração, os argumentos de são movidos para o final da lista de @hash 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 ele não for nulo. Caso contrário, ele avalia o operando direito e retorna seu resultado. O ?? operador não avalia seu operando direito se o operando esquerdo 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 seu operando esquerdo somente se o operando esquerdo for avaliado como nulo. O ??= operador não avalia seu operando direito se o operando esquerdo for avaliado como não-nulo.

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

100

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

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

1/10/2020

Operadores condicionais nulos

Nota

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 retornará null.

Como o PowerShell permite ? fazer 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]

Nota

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

Operador adicionado & para controle de trabalho

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 trabalho é 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, então Copy-Item $foo $bar & simplesmente funciona. 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 métodos Where 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:

• Alterações de comportamento ao comparar cadeias de caracteres no .NET 5+

A partir do .NET 5.0, as comparações de cadeia de caracteres invariantes de cultura ignoram 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 Remove-Service cmdlet 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.

• Disable-ExperimentalFeature
• Enable-ExperimentalFeature
• Get-ExperimentalFeature

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 vista 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 o ConciseView, se um erro não for de um erro de script ou analisador, então é uma mensagem de erro de linha única:

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

Nota

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 detalhada completa do erro totalmente qualificado, quando desejado. Por padrão, o cmdlet exibe os detalhes completos, incluindo exceções internas, do último erro que ocorreu.

O Get-Error cmdlet oferece suporte à entrada do pipeline usando a variável $Errorinterna . 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 a 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: 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, ele é incluído $windir\System32 automaticamente como parte da PSModulePath variável de ambiente. 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, -LiteralPath dado um curinga iria tratá-lo da mesma forma que -Path e se o curinga não encontrasse arquivos, ele sairia silenciosamente. O comportamento correto deve ser -LiteralPath literal, portanto, se o arquivo não existir, ele deve erro. Mudança é tratar curingas usados 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 comunicação remota RPC no CoreFX (particularmente em plataformas que não são Windows) e garantindo uma experiência de comunicação remota consistente no PowerShell, o -Protocol parâmetro foi removido dos \*-Computer cmdlets. 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.

Correção 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 nas linhas retornadas.

Alterações à Format-Hex

O -Raw parâmetro é agora um "no-op" (na medida em que não faz nada). No futuro, toda a saída é exibida com uma representação verdadeira de números que inclui todos os bytes para seu 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 Get-StringHash e Get-FileHash cmdlets

A alteração é que alguns algoritmos hash não são suportados pelo CoreFX, portanto já não estão disponíveis:

• MACTripleDES
• RIPEMD160

Adicionar validação em cmdlets em Get-* 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

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-se PSTypeNames na 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 alteração adiciona as informações de tipo ao membro, PSTypeNames se disponível no arquivo 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 Registro para Remove-Item

Anteriormente, -LiteralPath dado um curinga iria tratá-lo da mesma forma que -Path e se o curinga não encontrasse arquivos, ele sairia silenciosamente. O comportamento correto deve ser -LiteralPath literal, portanto, se o arquivo não existir, ele deve erro. Mudança é tratar 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, você pode ser quebrado por esta mudança se você 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 Password parâmetro, que leva um SecureStringarquivo . 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 no Windows chamada more wrapped more.com. Essa função foi agora removida.

Além disso, a help função mudou para usar more.com no Windows ou no pager padrão do sistema especificado por $env:PAGER em plataformas que não sã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 -- mude 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 de -Not parâmetro 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 em cmdlets da Web

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 Response propriedade em exceções do Web Cmdlet agora é um System.Net.Http.HttpResponseMessage objeto.
• A análise estrita de cabeçalho RFC agora é padrão para o -Headers parâmetro and -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 mais de -Credential 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 encerramento quando as tentativas de redirecionamento excedem o limite fornecido em vez de retornar os resultados do último redirecionamento.
• No PowerShell 6.2, uma alteração foi feita para padrão para codificação 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
• Parâmetro adicionado -Resume para 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 para Invoke-RestMethod serializar corretamente um literal JSON null de valor único válido como $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.

Tornar -OutFile o parâmetro em cmdlets da Web para funcionar como -LiteralPath

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

Alterações da API

Remover AddTypeCommandBase classe

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

Removido VisualBasic como 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.

Suporte removido 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 com ValueFromRemainingArguments funções PS

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

Usos limpos 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 do Depurador da classe abstrata que é usada apenas para depuração de fluxo de SetParent trabalho.
• Remova a mesma sobrecarga da classe derivada SetParent RemotingJobDebugger.

Não encapsular o resultado de retorno ao PSObject converter um ScriptBlock em um 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 a comunicação remota

PowerShell Remoting (PSRP) usando WinRM em plataformas Unix requer NTLM/Negotiate ou Basic Auth sobre 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 Comunicação remota SSH 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 primeiro tenta se conectar usando qualquer variável de ambiente disponível pwsh.exe na PATH variável. Se pwsh.exe não estiver disponível, o PowerShell Direct voltará a usar powershell.exeo .

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. Esse ponto de extremidade que pode ser usado em atualizações de versão secundária como a configuração de sessão do PowerShell 6 "em 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 POWERSHELL_TELEMETRY_OPTOUT de ambiente como true, yesou 1. Não suportamos mais a exclusão do arquivo DELETE_ME_TO_DISABLE_CONSOLEHOST_TELEMETRY para desativar a telemetria.