Новые возможности PowerShell 7.1

Статья
05/09/2024

11 ноября 2020 г. мы объявили о выпуске общедоступной версии PowerShell 7.1. Основываясь на фундаменте, заложенном в PowerShell 7.0, мы уделили больше внимания проблемам сообщества и реализовали ряд усовершенствований и исправлений. Мы стремимся поддерживать высокую стабильность и производительность платформы PowerShell.

Ниже перечислены новые функции, обновления и критические изменения в PowerShell 7.1.

PSReadLine 2.1.0 с прогнозной технологией IntelliSense
Версия PowerShell 7.1 опубликована в Microsoft Store.
Пакеты установщика обновлены для новых версий ОС с поддержкой ARM64.
4 новые экспериментальные функции; 2 экспериментальные функции стали основными.
Несколько критических изменений для повышения удобства использования

Полный список изменений доступен в журнале изменений в репозитории GitHub.

PSReadLine 2.1.0

Кроме того, PowerShell 7.1 включает версию PSReadLine 2.1.0. В ней реализована прогнозная технология IntelliSense. Дополнительные сведения о прогнозной технологии IntelliSense см. в объявлении, опубликованном в блоге PowerShell.

Пакет установщика в Microsoft Store

Версия PowerShell 7.1 опубликована в Microsoft Store. Этот выпуск PowerShell можно найти на веб-сайте Microsoft Store или в приложении Store в ОС Windows.

Пакет Microsoft Store обеспечивает следующие преимущества:

автоматические обновления, встроенные непосредственно в Windows;
интеграция с другими механизмами распространения программного обеспечения, такими как Intune и SCCM.

Примечание

Параметры конфигурации системного уровня, хранящиеся в $PSHOME, нельзя изменить. Это относится и к конфигурации WSMAN. Это означает, что вы не сможете подключать удаленные сеансы к установкам PowerShell на основе хранилища. Поддерживаются конфигурации уровня пользователя и удаленное взаимодействие по SSH.

Другие установщики

Более актуальные сведения о поддерживаемых операционных системах и жизненном цикле поддержки см. в статье Жизненный цикл поддержки PowerShell.

Обратитесь к инструкциям по установке для своей операционной системы:

Кроме того, PowerShell 7.1 поддерживает выпуски Debian и Ubuntu для ARM32 и ARM64, а также Alpine Linux для ARM64.

Сообщество также предоставило пакеты для Arch и Kali Linux, хотя они не поддерживаются официально.

Примечание

Debian 10+, CentOS 8+, Ubuntu 20.04, Alpine и ARM сейчас не поддерживают удаленное взаимодействие WinRM. Подробные сведения о настройке удаленного взаимодействия на основе SSH см. в статье Удаленное взаимодействие с PowerShell через SSH.

Экспериментальные возможности

Дополнительные сведения см. в статье об использовании экспериментальных функций.

В этом выпуске следующие экспериментальные функции стали основными:

В этом выпуске были добавлены следующие экспериментальные функции:

Microsoft.PowerShell.Utility.PSManageBreakpointsInRunspace
- В PowerShell 7.1 эта экспериментальная функция расширена: ко всем командлетам *-PSBreakpoint добавлен параметр Runspace. Параметр Runspace указывает объекту Runspace взаимодействовать с точками останова в указанном пространстве выполнения.
PSNativePSPathResolution — эта функция позволяет передавать пути к поставщикам PowerShell в собственные команды, которые не поддерживают синтаксис путей PowerShell.
PSCultureInvariantReplaceOperator — когда левый операнд в инструкции оператора -replace не является строкой, он преобразуется в строку. Когда эта функция включена, при преобразовании строк не используются настройки языка и региональных параметров.
PSSubsystemPluginModel — основа для поддержки будущих подключаемых модулей с прогнозной технологией IntelliSense.

Критические изменения и улучшения

Изменение в поведении при сравнении строк в .NET 5.0

Версия PowerShell 7.1 создана на основе версии .NET 5.0, в которой представлены следующие критические изменения:
- Изменения в поведении при сравнении строк в .NET 5+
Начиная с версии .NET 5.0, при сравнении неизменяемых строк не учитываются непечатаемые управляющие символы.

Например, следующие две строки считаются идентичными:
```
# Escape sequence "`a" is Ctrl-G or [char]7
'Food' -eq "Foo`ad"
```
```
True
```
Исправлено ошибочное значение $false для $? при записи собственной команды в stderr (#13395).

Обычно, когда собственные команды выполняют запись в stderr, им не нужно сообщать об ошибке. В результате этого изменения $? задается равным $false только в том случае, если собственная команда имеет ненулевой код выхода. Это изменение не связано с экспериментальной функцией PSNotApplyErrorActionToStderr.
Теперь $ErrorActionPreference не влияет на выходные данные stderr собственных команд (#13361).

Обычно, когда собственные команды выполняют запись в stderr, им не нужно сообщать об ошибке. В результате этого изменения выходные данные stderr по-прежнему фиксируются в объектах ErrorRecord, но среда выполнения больше не применяет $ErrorActionPreference, если ErrorRecord поступает от собственной команды.
Переименуйте -FromUnixTime в -UnixTimeSeconds on Get-Date , чтобы разрешить ввод времени Unix (No 13084) (выражаем благодарность). @aetos382!)

Параметр -FromUnixTime был добавлен в версии 7.1-preview.2. Он был переименован, чтобы лучше соответствовать типу данных. Этот параметр принимает целочисленное значение, которое представляет время в секундах с 0:00:00 1 января 1970 г.

В этом примере время в формате Unix (представленное количеством секунд с 0:00:00 01.01.1970) преобразуется в тип DateTime.
```
Get-Date -UnixTimeSeconds 1577836800

Wednesday, January 01, 2020 12:00:00 AM
```
Разрешено переопределять явно заданным именованным параметром аналогичный параметр из сплаттинга хэш-таблицы (#13162)

В результате этого изменения именованные параметры, передаваемые через сплаттинг, перемещаются в конец списка параметров, так что они привязываются после привязки всех явно указанных именованных параметров. При привязке параметров в простых функциях не возникает ошибка, если не удается найти указанный именованный параметр. Неизвестные именованные параметры привязываются к параметру $args простой функции. Перемещение сплаттинга в конец списка аргументов приводит к изменению порядка, в котором параметры следуют в $args.

Пример:
```
function SimpleTest {
    param(
        $Name,
        $Path
    )
    "Name: $Name; Path: $Path; Args: $args"
}
```
В предыдущем случае аргумент MyPath не привязан к -Path, так как он является третьим в списке аргументов. ## В результате он помещается в '$args' вместе с Blah = "World"
```
PS> $hash = @{ Name = "Hello"; Blah = "World" }
PS> SimpleTest @hash "MyPath"
Name: Hello; Path: ; Args: -Blah: World MyPath
```
В результате этого изменения аргументы из @hash перемещаются в конец списка аргументов. MyPath становится первым аргументом в списке, поэтому он привязывается к -Path.
```
PS> SimpleTest @hash "MyPath"
Name: Hello; Path: MyPath; Args: -Blah: World
```
Сделайте параметр -Qualifier switch не позициональным для Split-Path (No 12960) (выражаем благодарность) @yecril71pl!)
Разрешите рабочий каталог как литеральный путь для Start-Process , если он не указан (No 11946) (выражаем благодарность) @NoMoreFood!)
Сделайте -OutFile параметр в веб-командлетах работать как -LiteralPath (No 11701) (выражаем благодарность) @iSazonov!)
Исправлена привязка строковых параметров для BigInteger числовых литерал (No 11634) (выражаем благодарность) @vexx32!)
В Windows Start-Process создает среду процесса со всеми переменными среды из текущего сеанса, используя -UseNewEnvironment создание новой среды процесса по умолчанию (No 10830) (выражаем благодарность). @iSazonov!)
Устранен перенос возвращаемого результата в PSObject при преобразовании ScriptBlock в делегат (#10619).

Когда ScriptBlock преобразуется в тип делегата для использования в контексте C#, перенос результата в PSObject приводит к ненужным проблемам.
- Когда значение преобразуется в возвращаемый тип-делегат, PSObject по сути разворачивается. Поэтому PSObject не требуется.
- Если возвращаемый тип-делегат — object, он переносится в PSObject, что затрудняет работу с ним в коде C#.
В результате этого изменения возвращается базовый объект.

Share via