Udostępnij za pomocą


Co nowego w PowerShell 7.1

11 listopada 2020 roku ogłosiliśmy ogólną dostępność PowerShell 7.1. Opierając się na fundamentach ustanowionych w PowerShell 7.0, nasze działania koncentrowały się na problemach społeczności i obejmowały szereg usprawnień oraz poprawek. Zobowiązujemy się do tego, aby PowerShell pozostał stabilną i wydajną platformą.

PowerShell 7.1 zawiera następujące funkcje, aktualizacje i zmiany łamiące.

  • PSReadLine 2.1.0, który zawiera Predictive IntelliSense
  • PowerShell 7.1 został opublikowany w Microsoft Store
  • Pakiety instalacyjne zaktualizowane dla nowych wersji systemu operacyjnego z obsługą ARM64
  • 4 nowe funkcje eksperymentalne i 2 eksperymentalne funkcje promowane do głównego nurtu
  • Kilka zmian łamujących poprawę użyteczności

Aby uzyskać pełną listę zmian, zobacz CHANGELOG w repozytorium GitHub.

PSReadLine 2.1.0

PowerShell 7.1 zawiera także PSReadLine 2.1.0. Ta wersja zawiera Predictive IntelliSense. Więcej informacji o funkcji Predictive IntelliSense znajdziesz w ogłoszeniu na blogu PowerShell.

Pakiet instalacyjny Microsoft Store

PowerShell 7.1 został opublikowany w Microsoft Store. Wersję PowerShell znajdziesz na stronie Microsoft Store lub w aplikacji Store na Windows.

Zalety pakietu Microsoft Store:

  • Aktualizacje automatyczne wbudowane bezpośrednio w system Windows
  • Integruje się z innymi mechanizmami dystrybucji oprogramowania, takimi jak Intune i SCCM

Uwaga / Notatka

Nie można zmieniać żadnych ustawień konfiguracji na poziomie systemu, które są przechowywane w $PSHOME Obejmuje to konfigurację programu WSMAN. Zapobiega to nawiązywaniu połączenia sesji zdalnych z instalacjami programu PowerShell w wersji sklepowej. Obsługiwane są konfiguracje na poziomie użytkownika i komunikacja zdalna SSH.

Inni instalatorzy

Aby uzyskać więcej informacji o wspieranych systemach operacyjnych i cyklu życia up-todaty, zobacz cykl życia wsparcia PowerShell.

Sprawdź instrukcje instalacji preferowanego systemu operacyjnego:

Dodatkowo PowerShell 7.1 obsługuje warianty ARM32 i ARM64: Debian, Ubuntu oraz ARM64 Alpine Linux.

Chociaż nie jest oficjalnie wspierany, społeczność udostępniła także pakiety dla Arch i Kali Linux.

Uwaga / Notatka

Debian 10+, CentOS 8+, Ubuntu 20.04, Alpine i Arm obecnie nie obsługują zdalnych systemów WinRM. Szczegóły dotyczące konfiguracji zdalnego dostępu opartego na SSH można znaleźć w artykule PowerShell Reremote over SSH.

Funkcje eksperymentalne

Aby uzyskać więcej informacji na temat funkcji eksperymentalnych, zobacz Using Experimental Features.

Następujące eksperymentalne funkcje stały się obecnie podstawowymi w tej wersji:

W tym wydaniu dodano następujące eksperymentalne funkcje:

  • Microsoft.PowerShell.Utility.PSManageBreakpointsInRunspace

    • PowerShell 7.1 rozszerza tę eksperymentalną funkcję, dodając parametr Runspace do wszystkich *-PSBreakpoint cmdletów. Parametr Runspace określa obiekt Runspace , który ma wchodzić w interakcję z punktami przerwania w określonej przestrzeni biegu.
  • PSNativePSPathResolution – Ta funkcja pozwala przekazywać ścieżki dostawcy PowerShell do natywnych poleceń, które nie obsługują składni ścieżek PowerShell.

  • PSCultureInvariantReplaceOperator - Gdy lewy operand w instrukcji operatora -replace nie jest ciągiem znaków, ten operand jest konwertowany na ciąg znaków. Po włączeniu tej funkcji konwersja nie używa ustawień kultury do konwersji ciągów tekstów.

  • PSSubsystemPluginModel tworzy fundamenty pod wsparcie przyszłych wtyczek Predictive IntelliSense.

Zmiany i ulepszenia

  • Zachowanie porównywania ciągów znaków zmieniło się w .NET 5.0

    PowerShell 7.1 jest oparty na .NET 5.0, który wprowadził następującą zmianę łamiącą:

    Od .NET 5.0 porównania ciągów znaków niezmienniczych kultur ignorują znaki sterujące niedrukujące.

    Na przykład następujące dwie struny uważa się za identyczne:

    # Escape sequence "`a" is Ctrl-G or [char]7
    'Food' -eq "Foo`ad"
    
    True
    
  • Naprawa $? na nie, $false gdy natywne polecenie zapisuje się do (stderr#13395)

    Często natywne polecenia zapisują się bez stderr zamiaru sygnalizowania awarii. Ta zmiana $? jest ustawiona $false tylko wtedy, gdy natywne polecenie ma również niezerowy kod wyjścia. Ta zmiana nie jest związana z cechą PSNotApplyErrorActionToStderreksperymentalną .

  • Nie wpływaj $ErrorActionPreference na stderr wyjście natywnych poleceń (#13361)

    Często natywne polecenia zapisują się bez stderr zamiaru sygnalizowania awarii. Dzięki tej zmianie stderr wyjście nadal jest rejestrowane w obiektach ErrorRecord , ale czas wykonywania przestaje obowiązywać $ErrorActionPreference , jeśli ErrorRecord pochodzi z natywnego polecenia.

  • Przemianowanie -FromUnixTime na -UnixTimeSeconds on Get-Date , aby umożliwić wprowadzanie czasu w Unixie (#13084) (Dzięki @aetos382!)

    Parametr został -FromUnixTime dodany podczas podglądu wersji 7.1.2. Parametr został przemianowany, aby lepiej odpowiadał typowi danych. Parametr ten przyjmuje wartość całkowitą reprezentującą w sekundach od 1 stycznia 1970 roku, 0:00:00.

    Ten przykład przelicza czas Unix (reprezentowany przez liczbę sekund od 1970-01-01 0:00:00) na DateTime.

    Get-Date -UnixTimeSeconds 1577836800
    
    Wednesday, January 01, 2020 12:00:00 AM
    
  • Pozwól, by wyraźnie określony parametr nazwany zastąpił ten sam z hashtable splatting (#13162)

    Wraz z tą zmianą parametry nazwane ze splattingu są przenoszone na koniec listy parametrów, tak aby były ograniczone po tym, jak wszystkie wyraźnie określone parametry zostaną związane. Wiązanie parametrów dla funkcji prostych nie generuje błędu, gdy nie można znaleźć określonego parametru o nazwie. Nieznane parametry nazwane są powiązane z parametrem $args funkcji prostej. Przesunięcie splattingu na koniec listy argumentów zmienia kolejność, w jakiej parametry pojawiają się w .$args

    Przykład:

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

    W poprzednim zachowaniu MyPath nie jest związany z tym -Path , ponieważ jest trzecim argumentem na liście argumentów. ## Więc kończy się to upchanym w '$args' razem z Blah = "World"

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

    Dzięki tej zmianie argumenty z są @hash przenoszone na koniec listy argumentów. MyPath staje się pierwszym argumentem w liście, więc jest powiązany z .-Path

    PS> SimpleTest @hash "MyPath"
    Name: Hello; Path: MyPath; Args: -Blah: World
    
  • Niech parametr -Qualifier przełącznika nie jest pozycyjny dla Split-Path (#12960) (Dzięki @yecril71pl!)

  • Rozwiąż katalog roboczy jako dosłowną ścieżkę dla Start-Process sytuacji, gdy nie jest określona (#11946) (Dzięki @NoMoreFood!)

  • Zrób -OutFile parametr w cmdlets webowym, żeby działał na przykład -LiteralPath (#11701) (Dzięki @iSazonov!)

  • Napraw wiązanie parametrów ciągu dla BigInteger literali numerycznych (#11634) (Dzięki @vexx32!)

  • Na Windows tworzy Start-Process środowisko procesowe ze wszystkimi zmiennymi środowiskowymi z bieżącej sesji, używając -UseNewEnvironment nowego domyślnego środowiska procesu (#10830) (Dzięki @iSazonov!)

  • Nie opakuj wyniku PSObject , gdy konwertujesz a ScriptBlock na delegata (#10619)

    Gdy a ScriptBlock jest konwertowany na typ delegata do użycia w kontekście C#, opakowanie wyniku w a PSObject powoduje niepotrzebne problemy:

    • Gdy wartość zostanie przekształcona na typ delegate return, w zasadzie zostaje rozpakowana PSObject . Więc to PSObject jest niepotrzebne.
    • Gdy typ powrotu delegata to object, jest on owijany w , PSObject co utrudnia pracę w kodzie C#.

    Po tej zmianie zwracany obiekt jest obiektem bazowym.