Novità di PowerShell 7.1

Il 11 novembre 2020 abbiamo annunciato la disponibilità generale di PowerShell 7.1. Fondando gli sviluppi sulle basi consolidate di PowerShell 7.0, le nostre attività si sono concentrate sui problemi della community e includono una serie di miglioramenti e correzioni. Ci impegniamo a garantire che PowerShell rimanga una piattaforma stabile ed efficiente.

PowerShell 7.1 include le funzionalità, gli aggiornamenti e le modifiche di rilievo seguenti.

• PSReadLine 2.1.0, che include IntelliSense predittivo
• PowerShell 7.1 è stato pubblicato in Microsoft Store
• Pacchetti di installazione aggiornati per le nuove versioni del sistema operativo con supporto per ARM64
• 4 nuove funzionalità sperimentali e 2 funzionalità sperimentali promosse al mainstream
• Diverse modifiche di rilievo per migliorare l'usabilità

Per un elenco completo delle modifiche, vedere CHANGELOG nel repository GitHub.

PSReadLine 2.1.0

PowerShell 7.1 include anche PSReadLine 2.1.0. Questa versione include IntelliSense predittivo. Per altre informazioni sulla funzionalità IntelliSense predittivo leggere la comunicazione nel blog di PowerShell.

Pacchetto del programma di installazione di Microsoft Store

PowerShell 7.1 è stato pubblicato in Microsoft Store. È possibile trovare la versione di PowerShell nel sito Web Microsoft Store o nell'applicazione Store in Windows.

Vantaggi del pacchetto di Microsoft Store:

• Aggiornamenti automatici integrati in Windows
• Integrazione con altri meccanismi di distribuzione software come Intune e SCCM

Nota

Non è possibile modificare le impostazioni di configurazione a livello di sistema archiviate in $PSHOME, inclusa la configurazione WSMAN. In questo modo si impedisce alle sessioni remote di connettersi alle installazioni di PowerShell basate su Store. Sono supportate le configurazioni a livello di utente e la comunicazione remota SSH.

Altri programmi di installazione

Per informazioni aggiornate sui sistemi operativi supportati e il ciclo di vita del supporto, vedere Ciclo di vita del supporto di PowerShell.

Vedere le istruzioni di installazione per il sistema operativo preferito:

• Windows
• macOS
• Linux

PowerShell 7.1 supporta anche le versioni ARM32 e ARM64 Debian e Ubuntu e la versione ARM64 Alpine Linux.

Sebbene non siano supportati ufficialmente, la community ha offerto anche pacchetti per Arch e Kali Linux.

Nota

Debian 10+, CentOS 8+, Ubuntu 20.04, Alpine e Arm attualmente non supportano la comunicazione remota WinRM. Per informazioni dettagliate sulla configurazione della comunicazione remota basata su SSH, vedere Comunicazione remota di PowerShell su SSH.

Funzionalità sperimentali

Per altre informazioni sulle funzionalità sperimentali, vedere Uso delle funzionalità sperimentali.

Le funzionalità sperimentali seguenti sono ora funzionalità mainstream in questa versione:

• PSNullConditionalOperators
• PSUnixFileStat

Le funzionalità sperimentali seguenti sono state aggiunte in questa versione:

• Microsoft.PowerShell.Utility.PSManageBreakpointsInRunspace

  • PowerShell 7.1 estende questa funzionalità sperimentale per aggiungere il parametro Runspace a tutti i *-PSBreakpoint cmdlet. Il parametro Runspace specifica un oggetto Spazio di esecuzione per interagire con i punti di interruzione nello spazio di esecuzione specificato.

• PSNativePSPathResolution : questa funzionalità consente di passare i percorsi del provider di PowerShell ai comandi nativi che non supportano la sintassi del percorso di PowerShell.

• PSCultureInvariantReplaceOperator : quando l'operando a sinistra in un'istruzione -replace dell'operatore non è una stringa, tale operando viene convertito in una stringa. Con la funzionalità abilitata, la conversione non usa le impostazioni cultura per la conversione di stringhe.

• PSSubsystemPluginModel pone le basi per supportare i plug-in Predittivi IntelliSense futuri.

Modifiche e miglioramenti di rilievo

• Comportamento di confronto stringa modificato in .NET 5.0

  PowerShell 7.1 è basato su .NET 5.0, che ha introdotto la modifica di rilievo seguente:

  • Cambia il comportamento durante il confronto di stringhe in .NET 5+

  A partire da .NET 5.0, i confronti delle stringhe invarianti ignorano i caratteri di controllo non di stampa.

  Ad esempio, le due stringhe seguenti vengono considerate identiche:

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

  True
  

• Correzione $? da non essere $false quando il comando nativo scrive in stderr (#13395)

  È comune che i comandi nativi vengano scritti in stderr senza voler indicare un errore. Con questa modifica $? è impostata su $false solo quando il comando nativo ha anche un codice di uscita diverso da zero. Questa modifica non è correlata alla funzionalità PSNotApplyErrorActionToStderrsperimentale .

• Non $ErrorActionPreference influire sull'output stderr dei comandi nativi (#13361)

  È comune che i comandi nativi vengano scritti in stderr senza voler indicare un errore. Con questa modifica, stderr l'output viene ancora acquisito negli oggetti ErrorRecord , ma il runtime non si applica $ErrorActionPreference più se errorRecord proviene da un comando nativo.

• Rinominare -FromUnixTime su su -UnixTimeSecondsGet-Date per consentire l'input ora Unix (#13084) (grazie @aetos382!)

  Il -FromUnixTime parametro è stato aggiunto durante la versione 7.1-preview.2. Il parametro è stato rinominato in modo che corrisponda meglio al tipo di dati. Questo parametro accetta un valore intero che rappresenta in secondi dal 1° gennaio 1970, 0:00:00.

  In questo esempio viene convertito un tempo Unix (rappresentato dal numero di secondi dal 1970-01-01 01 0:00:00) a DateTime.

  Get-Date -UnixTimeSeconds 1577836800
  
  Wednesday, January 01, 2020 12:00:00 AM
  

• Autorizzazione per il parametro denominato specificato in modo esplicito a sostituire lo stesso parametro dallo splatting delle tabelle hash (#13162)

  Con questa modifica, i parametri denominati da splatting vengono spostati alla fine dell'elenco di parametri in modo che vengano associati dopo che tutti i parametri denominati specificati in modo esplicito siano associati. L'associazione di parametri per funzioni semplici non genera un errore quando non è possibile trovare un parametro denominato specificato. I parametri denominati sconosciuti sono associati al $args parametro della funzione semplice. Lo spostamento dello splatting alla fine dell'elenco di argomenti modifica l'ordine in cui vengono visualizzati i parametri in $args.

  Ad esempio:

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

  Nel comportamento precedente MyPath non è associato -Path perché è il terzo argomento nell'elenco degli argomenti. ## Quindi finisce di essere riempito in '$args' insieme a Blah = "World"

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

  Con questa modifica, gli argomenti da @hash vengono spostati alla fine dell'elenco di argomenti. MyPath diventa il primo argomento nell'elenco, quindi è associato a -Path.

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

• Impostare il parametro -Qualifier switch non posizionale per Split-Path (#12960) (Grazie @yecril71pl!)

• Risolvere la directory di lavoro come percorso letterale per Start-Process quando non è specificato (#11946) (Grazie) @NoMoreFood!)

• Impostare -OutFile il parametro nei cmdlet Web per funzionare come -LiteralPath (#11701) (Grazie @iSazonov!)

• Correzione dell'associazione di parametri stringa per BigInteger valori letterali numerici (#11634) (grazie) @vexx32!)

• In Windows Start-Process crea un ambiente di processo con tutte le variabili di ambiente della sessione corrente, usando -UseNewEnvironment crea un nuovo ambiente di processo predefinito (#10830) (Grazie) @iSazonov!)

• Non eseguire il wrapping del risultato PSObject restituito durante la conversione di un oggetto in un ScriptBlock delegato (#10619)

  Quando un ScriptBlock oggetto viene convertito in un tipo delegato da usare nel contesto C#, il wrapping del risultato PSObject comporta problemi non utilizzati:

  • Quando il valore viene convertito nel tipo restituito delegato, l'oggetto PSObject viene essenzialmente annullato. Quindi l'oggetto PSObject non è necessario.
  • Quando il tipo restituito delegato è object, viene eseguito il wrapping in un PSObject elemento che rende difficile l'uso nel codice C#.

  Dopo questa modifica, l'oggetto restituito è l'oggetto sottostante.