Neuerungen in PowerShell 7.1

Am 11. November 2020 wurde die allgemeine Verfügbarkeit von PowerShell 7.1 angekündigt. Aufbauend auf den in PowerShell 7.0 geschaffenen Grundlagen konzentrierten sich unsere Bemühungen auf in der Community gemeldete Issues und umfassen eine Reihe von Verbesserungen und Korrekturen. Wir engagieren uns dafür, dass PowerShell auch weiterhin eine stabile und leistungsstarke Plattform bleibt.

PowerShell 7.1 umfasst die folgenden Features, Updates und Breaking Changes.

• PSReadLine 2.1.0, einschließlich Predictive IntelliSense
• Veröffentlichung von PowerShell 7.1 im Microsoft Store
• Installerpakete für neue Betriebssystemversionen mit Unterstützung für ARM64 aktualisiert
• Höherstufung von vier neuen experimentellen und zwei experimentellen Features auf Mainstreamfeatures
• Mehrere Breaking Changes zur Verbesserung der Benutzerfreundlichkeit

Eine umfassende Liste der Änderungen finden Sie im Änderungsprotokoll im GitHub-Repository.

PSReadLine 2.1.0

Zu PowerShell 7.1 gehört auch PSReadLine 2.1.0. Diese Version enthält Predictive IntelliSense. Weitere Informationen zum Feature Predictive IntelliSense finden Sie im PowerShell-Blog in der Ankündigung.

Microsoft Store-Installerpaket

PowerShell 7.1 wurde im Microsoft Store veröffentlicht. Die PowerShell-Version finden Sie auf der Website von Microsoft Store oder in der Store-Anwendung unter Windows.

Vorteile des Microsoft Store-Pakets:

• Direkt in Windows integrierte automatische Updates
• Integration in andere Softwareverteilungsmechanismen wie Intune und SCCM

Andere Installer

Weitere aktuelle Informationen zu unterstützten Betriebssystemen und zum Supportlebenszyklus finden Sie unter PowerShell-Supportlebenszyklus.

Prüfen Sie die Installationsanweisungen für Ihr bevorzugtes Betriebssystem:

• Windows
• macOS
• Linux

Darüber hinaus unterstützt PowerShell 7.1 die ARM32- und ARM64-Varianten von Debian, Ubuntu und ARM64 Alpine Linux.

Wenngleich nicht offiziell unterstützt, hat die Community auch Pakete für Arch und Kali Linux bereitgestellt.

Experimentelle Features

Weitere Informationen zu den experimentellen Features finden Sie unter Verwenden experimenteller Features.

Die folgenden experimentellen Features stellen in diesem Release nun Mainstreamfeatures dar:

• PSNullConditionalOperators
• PSUnixFileStat

Die folgenden experimentellen Features wurden in diesem Release hinzugefügt:

• Microsoft.PowerShell.Utility.PSManageBreakpointsInRunspace

  • PowerShell 7.1 erweitert dieses experimentelle Feature, um allen *-PSBreakpoint-Cmdlets den Runspace-Parameter hinzuzufügen. Der Runspace-Parameter gibt ein Runspace-Objekt an, mit dem im angegebenen Runspace mit Haltepunkt en interagiert wird.

• PSNativePSPathResolution: Dieses Feature ermöglicht es Ihnen, PowerShell-Anbieterpfade an native Befehle zu übergeben, die die PowerShell-Pfadsyntax nicht unterstützen.

• PSCultureInvariantReplaceOperator: Wenn der linke Operand in einer -replace-Operatoranweisung keine Zeichenfolge ist, wird dieser Operand in eine Zeichenfolge konvertiert. Wenn das Feature aktiviert ist, werden für die Zeichenfolgenkonvertierung keine Kultureinstellungen verwendet.

• PSSubsystemPluginModel bildet die Grundlage für die Unterstützung zukünftiger Predictive IntelliSense-Plug-Ins.

Breaking Changes und Verbesserungen

• Verhalten beim Zeichenfolgenvergleich in .NET 5.0 geändert

  PowerShell 7.1 basiert auf .NET 5.0, wodurch folgender Breaking Change eingeführt wurde:

  • Verhaltensänderungen beim Vergleichen von Zeichenfolgen ab .NET 5

  Ab .NET 5.0 ignorieren kulturunabhängige Zeichenfolgenvergleiche nicht druckbare Steuerzeichen.

  Beispielsweise werden die folgenden beiden Zeichenfolgen als identisch betrachtet:

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

  True
  

• Fix $? darf nicht $false sein, wenn der native Befehl in stderr schreibt (#13395)

  Es kommt häufig vor, dass native Befehle ohne die Absicht in stderr schreiben, einen Fehler zu melden. Mit dieser Änderung wird $? nur auf $false festgelegt, wenn der native Befehl auch einen Exitcode ungleich null aufweist. Diese Änderung steht in keinem Zusammenhang mit dem experimentellen Feature PSNotApplyErrorActionToStderr.

• Veranlassen, dass $ErrorActionPreference sich nicht auf die stderr-Ausgabe nativer Befehle auswirkt (#13361)

  Es kommt häufig vor, dass native Befehle ohne die Absicht in stderr schreiben, einen Fehler zu melden. Mit dieser Änderung wird die stderr-Ausgabe weiterhin in ErrorRecord-Objekten aufgezeichnet, die Runtime wendet $ErrorActionPreference jedoch nicht mehr an, wenn ErrorRecord aus einem nativen Befehl stammt.

• Umbenennen in -FromUnixTime-UnixTimeSeconds ein Get-Date , um Unix-Zeiteingabe zuzulassen (#13084) (Vielen Dank @aetos382!)

  Der -FromUnixTime-Parameter wurde während 7.1-preview.2 hinzugefügt. Der Parameter wurde zwecks einer größeren Übereinstimmung mit dem Datentyp umbenannt. Dieser Parameter nimmt einen ganzzahligen Wert, der Datum und Uhrzeit seit dem 1 Januar 1970, 0:00:00, sekundengenau darstellt.

  In diesem Beispiel wird eine Unix-Zeitangabe (dargestellt durch die Anzahl von Sekunden seit dem 1970-01-01 0:00:00) in DateTime konvertiert.

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

• Explizit angegebenem benannten Parameter erlauben, denselben über das Splatting von Hashtabellen zu ersetzen (#13162)

  Mit dieser Änderung werden die benannten Parameter aus dem Splatting an das Ende der Parameterliste verschoben, sodass sie erst nach dem Binden aller explizit angegebenen benannten Parameter gebunden werden. Die Parameterbindung für einfache Funktionen löst keinen Fehler aus, wenn ein angegebener benannter Parameter nicht gefunden werden kann. Unbekannte benannte Parameter sind an den $args-Parameter der einfachen Funktion gebunden. Durch Verschieben des Splattings an das Ende der Argumentliste wird die Reihenfolge geändert, in der die Parameter in $args angezeigt werden.

  Beispiele:

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

  Im vorherigen Verhalten ist MyPath das dritte Argument in der Argumentliste und daher nicht an -Path gebunden. Aus diesem Grund wird MyPath zusammen mit Blah = "World" in $args platziert.

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

  Mit dieser Änderung werden die Argumente aus @hash an das Ende der Argumentliste verschoben. MyPath wird zum ersten Argument in der Liste, sodass es an -Path gebunden ist.

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

• Stellen Sie den Switch-Parameter -Qualifier nicht positional für Split-Path fest (#12960) (Vielen Dank @yecril71pl!)

• Auflösen des Arbeitsverzeichnisses als Literalpfad für Start-Process , wenn es nicht angegeben ist (#11946) (Vielen Dank @NoMoreFood!)

• Parameter -OutFile in Web-Cmdlets so gestalten, dass sie funktionieren wie -LiteralPath (#11701) (Vielen Dank @iSazonov!)

• Korrigieren der Zeichenfolgenparameterbindung für BigInteger numerische Literale (#11634) (Vielen Dank @vexx32!)

• Erstellt unter Windows Start-Process eine Prozessumgebung mit allen Umgebungsvariablen aus der aktuellen Sitzung, wobei -UseNewEnvironment eine neue Standardprozessumgebung erstellt wird (#10830) (Vielen Dank @iSazonov!)

• Zurückgegebenes Ergebnis nicht in PSObject umschließen, wenn ScriptBlock in einen Delegaten konvertiert wird (#10619)

  Wenn ScriptBlock in einen Delegattyp konvertiert wird, der im C#-Kontext verwendet werden soll, führt das Umschließen des Ergebnisses in PSObject zu unnötigen Problemen:

  • Wenn der Wert in den Rückgabetyp des Delegaten konvertiert wird, wird PSObject im Wesentlichen entpackt. PSObject ist daher nicht erforderlich.
  • Wenn der Rückgabetyp des Delegaten object ist, wird er in PSObject umschlossen, was die Verwendung in C#-Code erschwert.

  Nach dieser Änderung entspricht das zurückgegebene Objekt dem zugrunde liegenden Objekt.