PowerShell Core 6.0 — это новая версия хорошо знакомой многим системным администраторам командной оболочки и среды написания сценариев. С одной стороны, это уже не Windows PowerShell, а компонент с именем PowerShell Core, с другой — его версия 6.0, что вполне логично следует за преды­дущей 5.1. Так что же это такое? В чем отличие данного продукта от Windows PowerShell 5.1 и каковы особенности его использования? Попробуем разобраться.

Доступность

PowerShell Core 6.0, как следует из названия, построен на основе инфраструктуры. NET Core (если быть точным, то. NET Core 2.0), в отличие от компонента Windows PowerShell 5.1, созданного на базе инфраструктуры. NET Framework. Чем. NET Core отличается от своего более функционально полного собрата, так это тем, что данная инфраструктура содержит значительно меньший набор доступных для использования программных интерфейсов API. Другое, не менее значимое отличие состоит в том, что работает она не только на Windows, но и на системах *nix. И, как следствие, PowerShell Core 6.0 также работает теперь не только на Windows, но и на macOS, и нескольких дистрибутивах Linux. На сегодня поддерживаются следующие операционные системы:

  • Windows 7, 8.1, 10;
  • Windows Server 2008 R2, 2012 R2, 2016;
  • Windows Server Semi-Annual Channel;
  • Ubuntu 14.04, 16.04, 17.04;
  • Debian 8.7+, 9;
  • CentOS 7;
  • Red Hat Enterprise Linux 7;
  • OpenSUSE 42.2;
  • Fedora 25, 26;
  • macOS 10.12+.

Кроме того, существуют не поддерживаемые официально версии для Arch Linux, Kali Linux, дистрибутив в формате AppImage, а также экспериментальные версии для Windows на архитектурах ARM32 и ARM64 и Raspbian (Stretch).

Таким образом, мы подошли к одной из целей разработки PowerShell Core — это кроссплатформенность. Как неоднократно заявляли разработчики, они стремились к тому, чтобы новая версия PowerShell была доступна за пределами экосистемы Windows. С другой стороны, по их же словам, на сегодня позиционировать PowerShell в качестве командной среды по умолчанию на системах Linux не планируется. Еще не вполне ясны сценарии использования, степень принятия новой оболочки пользователями и еще множество различных нюансов.

«Облака»

Теперь перейдем к следующему фактору, определяющему существование PowerShell в его нынешнем виде. Это взаимодействие с «облачными» платформами. Причем не только Microsoft, но и других производителей. Для этой цели были в значительной степени переработаны команды для работы с веб-ресурсами, такие как Invoke-WebRequest, Invoke-RESTMethod и ConvertFrom-JSON.

Кроме того, одними из первых модулей, над которыми была начата работа по адаптации для PowerShell Core, были модули для управления Microsoft Azure. Сейчас поддерживается только небольшая часть всего набора модулей для «облачной» платформы Microsoft, но работа в этом направлении продолжается. Модули для Microsoft Azure, предназначенные для использования в PowerShell Core, вы можете найти в PowerShell Gallery при помощи следующей команды:

Find-Module -Name AzureRM.*Netcore

Таким образом, что касается значительных изменений в предполагаемых сценариях использования новой версии PowerShell, мы видим, что их два: поддержка Windows, Linux и macOS и расширение возможностей взаимодействия с различными «облачными» платформами.

Открытый код

Еще одно значительное изменение, имеющее определенное влияние на использование продукта, состоит в том, что PowerShell теперь является программным обеспечением с открытым исходным кодом, Open Source. С одной стороны, это должно сделать процесс разработки более открытым, гибким и динамичным, с возможностью получения быстрого отклика от пользователей и соответственно изменения приоритетов разработки с целью более полного соответствия нуждам потребителей. Что же касается сообщества пользователей, то открытость кода дает возможность не только влиять на процесс разработки, но и принимать в нем активное участие. Если, например, вам нужна некая функция, на разработку которой у команды сейчас нет ни времени, ни ресурсов — разработайте ее сами и предложите включить ваш код в следующий релиз PowerShell Core.

Чего не хватает

Теперь давайте перейдем к изменениям в функциональности. Начнем с того, чего вы не найдете в PowerShell Core 6.0.

Как уже упоминалось, инфраструктура. NET Core поддерживает использование лишь части доступных программных интерфейсов API, присутствующих в полной версии,. NET Framework. Это означает, что не все из того, что реализовано в Windows PowerShell 5.1, будет доступно в PowerShell Core 6.0.

Как заявляют разработчики, многие модули, созданные для использования в Windows PowerShell 5.1 и более ранних версиях, будут работать и в PowerShell Core. Однако это только в том случае, если модуль не использует какой-либо функции, отсутствующей в. NET Core или PowerShell версии 6.0. А список таких функций на данный момент довольно велик.

Здесь стоит подчеркнуть, что мы говорим именно о версии 6.0, поскольку целью разработчиков является перенос пусть и не всей функциональности версии 5.1 в PowerShell Core, но значительной ее части, и в первую очередь той, что активно применяется и востребована пользователями. И уже сейчас идет разработка PowerShell Core версии 6.1, где вопросы совместимости по-прежнему в приоритете.

Итак, в PowerShell Core 6.0 не поддерживаются следующие возможности и решения:

  • . NET Framework (FullCLR). Это логично, так как для реализации кроссплатформенности потребовалось перевести PowerShell на. NET Core.
  • Snap-ins. Дополнительно подключаемые модули широко использовались в Windows PowerShell 1.0, но уже со второй версии началось активное движение в сторону модулей функций, поэтому разработчиками было принято решение о прекращении поддержки этого компонента в новой версии PowerShell.
  • Workflows. Рабочие процессы, как отмечают разработчики, использовались в основном в двух сценариях — автоматизация в Azure и возможности параллельного выполнения команд. Для каждого из этих сценариев сейчас прорабатываются варианты решений, призванных заменить рабочие процессы другими механизмами.
  • WMI v1. Под поддержкой WMI версии 1 подразумевается использование следующих команд: Get-WmiObject, Invoke-WmiMethod, Register-WmiEvent, Remove-WmiObject и Set-WmiInstance. Еще в PowerShell 3.0 появился модуль CIMCmdlets (который иногда неофициально называют WMI v2), призванный заместить упомянутые выше команды за счет более точного соответствия стандартам, упрощенного синтаксиса и поддержки Tab-completion, то есть завершения имен параметров и их значений по нажатию клавиши Tab для классов и пространств имен WMI.

Отсутствуют и команды, так или иначе связанные с графическим отображением, такие, например, как Out-GridView, Show-Command и параметр -ShowWindow команды Get-Help.

Кроме того, в PowerShell Core работают не все модули из тех, что отлично себя показали в Windows PowerShell. Например, одним из следствий отсутствия поддержки подключаемых модулей стало то, что в PowerShell Core не работают модули ActiveDirectory и DnsClient.

Также, по причине использования API, отсутствующих в. NET Core, не работают модуль Microsoft.PowerShell.LocalAccounts и команды Get-Counter, Export-Counter и Import-Counter.

Вследствие некоторых сложностей с RPC в CoreFX было решено убрать из нескольких команд параметр -ComputerName. В частности, теперь он недоступен в командах Get-Process, Get-Service, Add-Computer и еще нескольких. Вместо этого предлагается использовать следующий подход:

Invoke-Command
   -ComputerName computer_name
   -ScriptBlock {Get-Process}

Что касается остальных, не входящих в PowerShell Core по умолчанию модулей, их функциональность в значительной степени реализуема, однако не гарантируется.

Именно поэтому сейчас в переменной среды PSModulePath для PowerShell Core отсутствуют пути к модулям, доступным из Windows PowerShell, то есть по умолчанию воспользоваться ими из PowerShell Core вы не сможете. Однако это можно исправить, добавив нужные пути вручную или же установив модуль WindowsPSModulePath из PowerShell Gallery и запустив команду Add-WindowsPSModulePath. Например, так:

Install-Module WindowsPSModulePath
Add-WindowsPSModulePath

Кроме того, сообщается о разработке WindowsPowerShellCompatibility­Pack, модуля, призванного повысить совместимость PowerShell Core с существующими в Windows PowerShell модулями и командами, однако подробностей на данный момент не так уж много.

Издание шестое, исправленное и дополненное

Теперь давайте поговорим об изменениях и дополнениях, их в PowerShell Core предостаточно. Тем не менее сразу оговоримся, что статья не претендует на подробное описание каждого из них, поэтому предлагаю ограничиться только наиболее заметными.

Кроме привычного протокола WinRM, для выполнения удаленных подключений вы можете использовать и SSH. Реализуется это при помощи OpenSSH, который не только доступен на github.com (https://github.com/powershell/

Win32-OpenSSH), но и входит в качестве дополнительного компонента в Windows 10 Fall Creators Update и Windows Server 1709. Только имейте в виду, что на данный момент OpenSSH все еще находится в состоянии бета-версии, и, как следствие, официально не поддерживается.

Оператор & получил еще одно значение. И это, как и некоторые другие изменения, является следствием движения PowerShell в сторону Linux. Теперь, указывая его в конце выражения, вы показываете, что предшествующая оператору команда должна выполняться в качестве фонового задания. Например, так:

Get-Process &

Результаты выполнения команд Export-Csv и ConvertTo-Csv теперь не содержат по умолчанию строку с указанием типа данных. Например:

#TYPE System.Diagnostics.Process

Для того чтобы среди результатов она все же присутствовала, вы можете воспользоваться новым параметром — IncludeTypeInformation.

Оператор «..» (range operator) теперь поддерживает работу не только с числовыми данными, но и с символами. Например:

'a'..'z'

В качестве кодовой страницы теперь используется UTF-8 NoBOM.

Имя исполняемого файла PowerShell Core было изменено на pwsh.exe для Windows и pwsh для Linux и macOS.

Кроме того, был изменен порядок аргументов файла pwsh.exe. Если раньше первым аргументом был -Command, что позволяло не указывать его при вызове PowerShell, например так:

powershell.exe Get-Process

то теперь, в целях обеспечения удобства работы в Linux-среде, первым параметром является -File. Это дает вам возможность вызывать PowerShell для выполнения файлов сценариев без указания имени параметра:

pwsh C:\script.ps1

Однако для выполнения какой-либо команды теперь потребуется указывать параметр -Command или его сокращенный вариант -c.

pwsh.exe -Command Get-Process
pwsh.exe -c Get-Process

Для разработчиков

Если вы сами создаете модули, то пока тестировать их на предмет совместимости с PowerShell Core придется вручную. Однако уже сейчас разработчики говорят о планах добавить в модуль PSScriptAnalyzer необходимые правила для проверки сценариев и модулей на совместимость с новой версией PowerShell.

Если же вы уверены в том, что ваш модуль замечательно себя чувствует как в Windows PowerShell, так и в PowerShell Core, то перед публикацией в PowerShell Gallery можете отметить его тегами ‘PSEdition_Desktop’ и ‘PSEdition_Core’ соответственно, что поможет пользователям ваших сценариев и функций работать с ними более уверенно.

Совместное существование

PowerShell Core построен таким образом, чтобы никак не зависеть от Windows PowerShell. Поэтому одновременное присутствие обеих версий PowerShell в системе (естественно, если мы говорим о Windows) является не только возможным, но и, учитывая определенные различия в функциональности, вполне желательным вариантом.

Для этого было внесено несколько изменений. Как уже говорилось, имя исполняемого файла PowerShell Core для Windows было изменено с powershell.exe на pwsh.exe. Таким образом, если для выполнения какой-либо задачи вам нужна определенная версия PowerShell, будь то Windows PowerShell или PowerShell Core, указывать полный путь не потребуется, достаточно указать powershell.exe или pwsh.exe. Однако, если на вашей системе установлено несколько версий PowerShell Core, что тоже приемлемо, указывать полный путь к файлу pwsh.exe вам, вероятно, все же придется.

В Linux и mac–OS имя файла — pwsh, что созвучно по отношению к другим оболочкам этих операционных систем.

Автоматическая переменная $PSVersionTable теперь обладает свойством PSEdition, значение которого в Windows PowerShell 5.0 и 5.1 равно ‘Desktop’, а в PowerShell Core (как в PowerShell Core 6.0 для Windows, Linux и macOS, так и в PowerShell Core 5.0 и 5.1 для Nano Server), соответственно, ‘Core’.

Для того чтобы при создании сценариев вы могли задавать отдельные условия для их выполнения в зависимости от версии PowerShell, а также платформы, на которой они выполняются, были добавлены автоматические переменные: $IsCoreCLR, которая в PowerShell Core всегда равняется $true (другое дело, что в Windows PowerShell она отсутствует), а также $IsWindows, $IsLinux и $IsMacOS, значения которых равны $true в соответствующих операционных системах.

Папки модулей для каждой версии PowerShell также расположены в разных местах. Если для Windows PowerShell это

C:\WINDOWS\system32\
   WindowsPowerShell\v1.0\Modules,
C:\Program Files\
   WindowsPowerShell\Modules,
C:\Users\user_name\Documents\
   WindowsPowerShell\Modules,
то для PowerShell Core:
C:\Program Files\PowerShell\Modules,
C:\Program Files\powershell\
   powershellcore_version\Modules,
C:\Users\user_name\Documents\
   PowerShell\Modules,

где user_name — это имя пользователя, а powershellcore_version — версия PowerShell Core, например 6.0.0, 6.0.1 и т. д., что дает нам возможность устанавливать отдельные модули (или же их версии) для разных версий PowerShell Core.

То же касается и файлов профилей, которые находятся теперь в C:\ProgramFiles\PowerShell\powershellcore_version\ для всех пользователей и в C:\Users\user_name\Documents\PowerShell для каждого отдельного пользователя.

Подходит ли это вам

От этой версии не стоит ожидать прорывной функциональности. Как неоднократно говорили разработчики, в версии 6.0 их задача состояла в том, чтобы перенести базовые возможности на Linux и macOS. Наполнение PowerShell Core остальными функциями — это задача для будущих версий. Кроме того, стоит понимать, что набор функций, доступный сейчас в Windows PowerShell 5.1, перейдет в версию Core не скоро, не весь и, возможно, не в том виде, в котором он реализован сейчас.

С некоторыми допущениями можно сказать, что на данный момент PowerShell Core — это инструмент для решения несколько иных задач, нежели Windows PowerShell. Поэтому, если вам не требуется работать с «облачными» технологиями и различными операционными системами, то с изучением нового продукта, пожалуй, можно и не торопиться.

Однако со временем ситуация может измениться радикальным образом. PowerShell Core получит недостающие функции, а также приобретет новые. И тогда, возможно, уже Windows PowerShell будет восприниматься в качестве «младшего брата». Так что откладывать знакомство с PowerShell Core надолго все же не стоит.

Кроме того, ничто вам не мешает держать на панели задач оба ярлыка. А то и все три, если добавить ежедневные сборки: https://blogs.msdn.microsoft.com/powershell/2017/11/17/powershell-core-6-release-candidate/.

Что дальше?

Начнем с того, что Windows PowerShell никуда не денется. С другой стороны, значительного развития тоже не предвидится. Разработчики допускают выпуск следующей версии, скажем, 5.2, только если на то будут серьезные причины. Например, добавление в продукт некоей абсолютно необходимой функции. При этом предполагается, что доступна она будет только в очередной версии Windows 10, хотя окончательной ясности пока нет. Сегодня обсуждается только возможность внесения в версию 5.1 небольших исправлений. На GitHub эти предложения отмечены как Consider-WindowsPowerShell51.

Что же касается PowerShell Core, то в июне-июле этого года планируется выпуск версии 6.1. Приоритетные направления разработки выглядят следующим образом:

  • совместимость PowerShell Core с DeviceGuard/AppLocker;
  • возможность выполнять подписанные блоки кода в режиме FullLanguage на ограниченных конечных точках удаленных систем;
  • дальнейшая работа над совместимостью PowerShell Core с существующими модулями;
  • реализация встроенной многозадачности, отчасти в качестве замены рабочим процессам (workflows);
  • система подсказок при интерактивной работе, как локальная, так и с применением «облачных» технологий;
  • возможность включать и отключать определенную функциональность, например нечто экспериментальное или несовместимое с имеющимися компонентами;
  • перевод справочной системы на использование Markdown;
  • реализация возможности использования команды sudo при удаленном подключении;
  • разработка команды Enable-SSHRemoting для настройки удаленного доступа с использованием SSH, аналогично существующему Enable-PSRemoting для протокола WSMan;
  • создание модуля PowerShell для Internet of Things (IoT).

DSC

Отдельно стоит сказать о модуле Desired State Configuration (DSC). Считается, что в его нынешнем виде проект завершен, и мы можем использовать все предлагаемые возможности для настройки Windows и, в определенной степени, Linux.

Однако и в данном случае это еще не конец. Как сообщается, сейчас находится в разработке и готовится выйти в пространство Open Source новая версия Local Configuration Manager (LCM), компонента, который, собственно, и превращает ваши файлы параметров в настроенные должным образом системы.

И на этот раз предполагается, что данный компонент будет кроссплатформенным, с поддержкой ресурсов, созданных при помощи Windows PowerShell, PowerShell Core, C++ и Python. Тем не менее информации по нему на данный момент очень немного.

Установка

Итак, если вы решили, что настало время познакомиться с PowerShell Core 6.0, найти его, равно как и инструкции по установке для различных платформ, можно по следующим ссылкам:

  • Windows: https://aka.ms/getps6-windows;
  • Linux: https://aka.ms/getps6-linux;
  • GitHub: https://github.com/powershell/powershell.