Novidades no PowerShell 7.1

Em 11 de novembro de 2020, anunciamos a disponibilidade geral do PowerShell 7.1. Baseando-nos na base estabelecida no PowerShell 7.0, nossos esforços focaram em questões comunitárias e incluem várias melhorias e correções. Estamos comprometidos em garantir que o PowerShell permaneça uma plataforma estável e de alto desempenho.

O PowerShell 7.1 inclui os seguintes recursos, atualizações e mudanças de emergência.

PSReadLine 2.1.0, que inclui o IntelliSense Preditivo
O PowerShell 7.1 foi publicado na Microsoft Store
Pacotes de instaladores atualizados para novas versões do sistema operacional com suporte ao ARM64
4 novos recursos experimentais e 2 recursos experimentais promovidos ao mainstream
Várias mudanças importantes para melhorar a usabilidade

Para obter uma lista completa de alterações, consulte o CHANGELOG no repositório GitHub.

PSReadLine 2.1.0

O PowerShell 7.1 também inclui o PSReadLine 2.1.0. Esta versão inclui o IntelliSense Preditivo. Para mais informações sobre o recurso Predictive IntelliSense, veja o anúncio no blog PowerShell.

Pacote de instalador da Microsoft Store

O PowerShell 7.1 foi publicado na Microsoft Store. Você pode encontrar a versão PowerShell no site da Microsoft Store ou no aplicativo Store no Windows.

Benefícios do pacote da Microsoft Store:

Atualizações automáticas integradas diretamente no Windows
Integra-se com outros mecanismos de distribuição de software como Intune e SCCM

Observação

Quaisquer configurações de configuração em nível de sistema armazenadas $PSHOME não podem ser modificadas. Isso inclui a configuração do WSMAN. Isso impede que as sessões remotas se conectem a instalações baseadas na Store do PowerShell. Há suporte para configurações no nível do usuário e para comunicação remota SSH.

Outros instaladores

Para mais informações up-todata sobre sistemas operacionais suportados e ciclo de vida de suporte, veja o Ciclo de Vida de Suporte PowerShell.

Confira as instruções de instalação do seu sistema operacional preferido:

Além disso, o PowerShell 7.1 suporta versões ARM32 e ARM64 do Debian, Ubuntu e ARM64 Alpine Linux.

Embora não seja oficialmente suportado, a comunidade também forneceu pacotes para Arch e Kali Linux.

Observação

Debian 10+, CentOS 8+, Ubuntu 20.04, Alpine e Arm atualmente não suportam remotis do WinRM. Para detalhes sobre como configurar remotos baseados em SSH, veja PowerShell Remoting over SSH.

Recursos experimentais

Para obter mais informações sobre os recursos experimentais, consulte Usando recursos experimentais.

Os seguintes recursos experimentais agora são recursos comuns nesta versão:

Os seguintes recursos experimentais foram adicionados nesta versão:

Microsoft.PowerShell.Utility.PSManageBreakpointsInRunspace
- O PowerShell 7.1 estende essa funcionalidade experimental para adicionar o parâmetro Runspace a todos *-PSBreakpoint os cmdlets. O parâmetro de espaço de execução especifica que um objeto de espaço de execução interage com pontos de interação no espaço especificado.
PSNativePSPathResolution - Esse recurso permite que você passe caminhos de provedor PowerShell para comandos nativos que não suportam sintaxe de caminho PowerShell.
PSCultureInvariantReplaceOperator - Quando o operando da esquerda em uma -replace instrução de operador não é uma string, esse operando é convertido em uma string. Com o recurso ativado, a conversão não usa configurações de Cultura para conversão de strings.
PSSubsystemPluginModel prepara as bases para suportar futuros plug-ins Preditivos IntelliSense.

Mudanças e Melhorias Recentes

O comportamento de comparação de strings mudou no .NET 5.0

O PowerShell 7.1 é construído sobre o .NET 5.0, que introduziu a seguinte mudança de quebra:
- Mudanças de comportamento ao comparar strings no .NET 5+
A partir do .NET 5.0, comparações de strings invariantes por cultura ignoram caracteres de controle que não imprimem.

Por exemplo, as duas cadeias seguintes são consideradas idênticas:
```
# Escape sequence "`a" is Ctrl-G or [char]7
'Food' -eq "Foo`ad"
```
```
True
```
Correção $? para não ser $false quando o comando nativo escreve em stderr (#13395)

É comum que comandos nativos escrevam sem stderr a intenção de indicar uma falha. Com essa mudança $? , é definido apenas $false quando o comando nativo também possui um código de saída diferente de zero. Essa mudança não está relacionada à característica PSNotApplyErrorActionToStderrexperimental .
Não $ErrorActionPreference afete stderr a saída dos comandos nativos (#13361)

É comum que comandos nativos escrevam sem stderr a intenção de indicar uma falha. Com essa mudança, stderr a saída ainda é capturada em objetos ErrorRecord , mas o runtime não se aplica $ErrorActionPreference mais se o ErrorRecord vier de um comando nativo.
Renomeie -FromUnixTime para -UnixTimeSeconds ligado Get-Date para permitir entrada de tempo Unix (#13084) (Obrigado @aetos382!)

O -FromUnixTime parâmetro foi adicionado durante o 7.1-preview.2. O parâmetro foi renomeado para melhor corresponder ao tipo de dado. Esse parâmetro recebe um valor inteiro que representa em segundos desde 1º de janeiro de 1970, 0:00:00.

Este exemplo converte um tempo Unix (representado pelo número de segundos desde 1970-01-01 0:00:00) para DataTime.
```
Get-Date -UnixTimeSeconds 1577836800

Wednesday, January 01, 2020 12:00:00 AM
```
Permita que o parâmetro nomeado especificado explicitamente substitua o mesmo do splatting de hashtable (#13162)

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

Por exemplo:
```
function SimpleTest {
    param(
        $Name,
        $Path
    )
    "Name: $Name; Path: $Path; Args: $args"
}
```
No comportamento anterior, MyPath não está vinculado porque -Path é o terceiro argumento na lista de argumentos. ## Então 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 mudança, os argumentos de @hash são movidos para o final da lista de argumentos. MyPath torna-se o primeiro argumento da lista, então está vinculado a -Path.
```
PS> SimpleTest @hash "MyPath"
Name: Hello; Path: MyPath; Args: -Blah: World
```
Faça o parâmetro -Qualifier do switch não posicional para Split-Path (#12960) (Obrigado @yecril71pl!)
Resolva o diretório de trabalho como caminho literal para Start-Process quando não for especificado (#11946) (Obrigado @NoMoreFood!)
Faça -OutFile o parâmetro nos web cmdlets funcionar como -LiteralPath (#11701) (Obrigado @iSazonov!)
Corrigir a ligação de parâmetros de string para BigInteger literais numéricos (#11634) (Obrigado @vexx32!)
No Windows, Start-Process cria um ambiente de processo com todas as variáveis de ambiente da sessão atual, usando -UseNewEnvironment cria um novo ambiente padrão de processo (#10830) (Obrigado @iSazonov!)
Não envolva o resultado de retorno ao PSObject converter a ScriptBlock em um delegado (#10619)

Quando a ScriptBlock é convertido para um tipo delegado para ser usado no contexto de C#, envolver o resultado em a PSObject traz problemas desnecessários:
- Quando o valor é convertido para o tipo de retorno de delegado, o PSObject valor é essencialmente desembrulhado. Então isso PSObject não é necessário.
- Quando o tipo de retorno de delegado é object, ele é enrolado em a PSObject , tornando difícil trabalhar em código C#.
Após essa alteração, o objeto retornado é o objeto subjacente.

Last updated on 2021-10-04

Compartilhar via