PowerShell Core достиг фазы Beta.1


Развитие PowerShell Core успешно продолжается. Продуктовая группа к началу конференции Build 2017 выпустила PowerShell Core Beta.1.

Эту версию вы можете свободно скачать, установить и даже применять на практике. Было бы даже очень полезно попробовать её в своей ежедневной работе и написать свои замечения разработчикам, или даже что-то исправить самому — проект же открытый!

Всё ещё существует множество проблем, которые нужно решить. Почитайте v6.0.0-beta.1 release of PowerShellCore.

Например, внезапно, Beta.1 не работает на Windows 7 SP1. Причина банальна: PowerShell Core был переведен на .Net Core 2.0, где большое количество устаревшего API просто нет.

.Net Core 2.0 также находится в стадии активной разработки, поэтому с каждым днём всё больше API портируется на Unix и добавляется в поддержку. Вы можете опробовать .Net Core 2.0 в своих проектах и написать разработчикам свои замечания или принять участие в исправлении проблем — проект .Net Core 2.0 также открытый.

Надо особо отметить, что перевод PowerShell Core на .Net Core 2.0 расширил совместимость со старыми модулями: некоторые из них могут, внезапно, начать работать в Beta.1.

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

Исправлено множество нюансов при работе с файловыми системами на разных платформах. Работа в этом направлении продолжается. Было бы прекрасно получить замечания от сообщества уже сейчас, потому что реального опыта использования PowerShell на различных платформах пока ещё очень мало — поделитесь своим опытом и своими потребностями с разработчиками PowerShell.

В Beta.1 вы также обнаружите, что поправлена кодировка при работе с консолью: на Windows это теперь работает точно также как в Windows PowerShell. На Unix используется Utf8 (без BOM). Это обеспечивает хорошую обратную совместимость на Windows, но оставляет открытым вопрос о будущем: например, команда разработки Windows Console проводит большую работу по развитию консоли Windows и поддержке unicode-ных приложений. В тоже время нужно обязательно сохранить обратную совместимость и обеспечить работу существующих приложений.

Открытым остаётся вопрос по использованию кодировок при работе с файлами. Windows давно и полностью использует вариант Unicode Utf16LE с BOM, в то время как Unix применяет Utf8 без BOM. Сейчас продолжается большая и важная дискуссия по поводу использования кодировок в PowerShell Core — примите участие! Вопрос не так прост, как кажется на первый взгляд, поэтому ваше мнение важно для разработчиков.

 

О пользе -noprofile в PowerShell


В PowerShell есть параметр командной строки «-noprofile», который исключает загрузку пользовательских конфигурационных файлов.

В некоторых случаях нам не следует забывать использовать этот параметр. Например, при запуске скриптов в планировщике. Даже для пользовательских скриптов плохо зависеть от внешних непредсказуемых настроек. Если же речь идет о системных скриптах, то использование параметра «-noprofile» становится критически важным: злоумышленник может внедриться в системные скрипты и натворить плохих дел.

Об использовании утверждённых глаголов в PowerShell


Как известно в PowerShell есть список утверждённых глаголов, рекомендованных для использования в именах командлетов и функций. Этот список можно получить с помощью командлета Get-Verb.

Использование утверждённых глаголов упрощает поиск и понимание назначения командлетов и функций.

Насколько эти рекомендации выполняются? Собрать общую статистику невозможно. Но  один из ведущих участников команды разработчиков Jason Shirk привёл такой пример относительно имён модулей:


$verbs = (Get-Verb).Verb; Find-Module |
? { $modName = $_.Name; $verbs |
? { $modName.StartsWith($_) } }

Этот код ищет в Интернет репозитории все модули, имена которых начинаются с утвержденного глагола. Получается около 100 модулей, в которых авторы использовали утверждённые глаголы (скорее всего) не по назначению, вводя в заблуждение пользователей или осложняя поиск необходимых модулей.

Как заключил Jason Shirk, удивительно, как много нарушений рекомендованной практики!

Будьте более аккуратны при именовании модулей, особенно если вы собираетесь опубликовать их в репозитории.

Get Exchange Server MAPI logs for following analyze


Опубликовал скрипт, о котором ещё год назад писал Анализ логов MAPIMB.

Скрипт опубликован в TechNet Gallery.

Скрипт предназначен для облегчения анализа логов MAPIoverHTTP. Он хорошо самодокументирован и не требует тут дополнительных комментариев — качайте и используйте.

PowerShell 6 — скоро Beta1


Хорошая новость: в планах команды PowerShell 6 перевести проект из фазы Alfa в фазу Beta1 в начале мая 2017 года.

Это говорит о серьезном прогрессе проекта. За последний год команда сделала абсолютно работоспособный и стабильный продукт. Почему же тогда только Beta1? Потому что предстоит ещё много чего сделать. Составлен План работ. Вы можете с ним ознакомится, внести предложения, найти что-то важное для вас и сделать патч :-) Не обязательно делать что-то грандиозное.Любой вклад приветствуется. Даже простая регистрация проблемы, бага или предложения — добро пожаловать!

Powershell – END {} это важно!


При написании командлетов (cmdlet) и расширенных функций (advanced function) нужно соблюдать определённые правила.

Вот одно такое правило:

Основная логика (вывода результатов) должна быть помещена в END {} (или Endprocessing для C#)

Если не следовать этому правилу, то мы можем получить причудливые результаты. Один из разработчиков Powershell Jason Shirk продемонстрировал это следующим примером:

PS C:\>function BeginMarlezonBalet { end { write-host 'Первая часть марлезонского балета!'}}
PS C:\>function EndMarlezonBalet { begin { write-host 'Вторая часть марлезонского балета!'}}
PS C:\>BeginMarlezonBalet | EndMarlezonBalet

Вторая часть марлезонского балета!
Первая часть марлезонского балета!

Powershell 6 — новый командлет Get-Uptime


Да теперь моими усилиями в Powershell 6 есть командлет Get-Uptime, который, как можно легко понять, возвращает длительность работы ОС или время старта системы.

Как оказалось это нетривиальная задача. Основная проблема в том, что командлет должен работать на всех системах Windows, OSX и Linux. Например Windows мы можем получить зачение Uptime несколькими способами: 1. используя WMI класс Win32_OperatingSystem — это выполняется медленно и работает только на Windows, 2. используя счётчик производительности «System Uptime» — это наиболее правильный способ для Windows, но он не работает на других системах.

В конечном итоге оказалось возможным использовать класс .Net Stopwatch Class (System.Diagnostics). Это нецелевое использование этого класса. Тем не менее нашёлся хитрый вариант, который работает. Подробности можно найти по ссылке #2497.