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

>> PS PKI Module v0.9.2 <<

Однако, хочу добавить одну полезную (для меня) вещицу. На главной я вывешиваю список всех командлетов, которые есть в модуле с алиасами, если есть и ссылками на страницы wiki со справкой для командлетов. Некоторые могут подумать, что я это делаю вручную (первый раз я действительно делал в ручную и сильно устал). Конечно же, можно делать вручную, а можно и автоматически генерировать текст (если быть точнее, полный код HTML) при помощи PowerShell. Здесь есть много логики — ссылки на справку командлетов содержат их названия: http://pspki.codeplex.com/wikipage?title=CmdletName. Т.е. достаточно иметь основную часть ссылки и просто в конец добавлять название командлета. Однако, для ряда командлетов я применяю алиасы, чтобы можно было вводить команды покороче. Чтобы определить, есть ли у командлета алиасы, можно сделать вот так:

Вот так вы можете узнать, есть ли у командлета алиас или нету (тогда пошик насыпет вам много красного). Т.е. можно написать несколько строчек кода:

# через Get-Command получаем список команд, типа функции (по дефолту Get-Command
# выдаёт всё, что относится к командам, включая алиасы), которые относятся к
# конкретному модулю
gcm -Module pki -CommandType function | %{
# определяем, есть ли алиас у командлета
$alias = gal -Definition $_.name -ea 0
# если есть, тогда делаем код HTML с алиасом
if ($alias) {
@"
<li><a href="http://pspki.codeplex.com/wikipage?title=$($_.name)">$($_.name)</a> (Alias: <strong>$($alias.name)</strong>) </li>
"@    
} else {
# если нету, тогда просто код HTML без алиаса
@"
<li><a href="http://pspki.codeplex.com/wikipage?title=$($_.name)">$($_.name)</a> </li>
"@}
}

и всё. Просто в конце добавляете '| clip', чтобы он весь код HTML не выкидывал в консоль, а буфер обмена и получаете профит. Просто вставляете в редактор кодеплекса и всё.

Естественно, это была реклама пошика

Примечание: сведения в данной статье могут содержать фрагменты диктовки Капитана Очевидности и скорее всего приведены только для освежения памяти.

Часть 1 — $_

Давным-давно, Вася Гусев как-то сотворил артикль: Непонятные штуки – $_ и %. Как показала практика (хотя, я с этой практикой не сильно согласен), эти штуки до сих пор (даже после Васиного срыва покровов) остаются непонятными для рядовых администраторов у которых нет интегрированного парсера и отладчика скриптов в голове. Если  со знаком процента ещё можно бороться (т.е. не использовать его в качестве алиаса Foreach-Object), то с $_ бороться тяжело. Тут даже дело не в том, что бороться, а просто объяснить пользователям, что это такое. Что это такое — можно почитать у Васи. Если вы ленивые, тогда объясняю: $_ представляет собой динамическую переменную, которая хранит значение текущего элемента в конвейере.

Пара слов о понимании. Например, переменная $files для пользователя выглядит достаточно понятной — в ней какой-то список файлов. $_ для пользователя уже непонятна — в ней хранится нечто. В PowerShell 2.0 появилась возможность избежать использования этой мутной перменной в advanced functions. Вот краткая история:

• PowerShell 1.0

function EnumItems {
    process {
        Write-Host Current pipeline item: $_
    }
}

И запустите: 1..5 | EnumItems 0

Здесь других вариантов представить текущий элемент конвейера не представляется возможным, только через $_.

• PowerShell 2.0

В PowerShell 2.0 предыдущий код будет работать, пока вы не превратите простую функцию в advanced:

function EnumItems {
[CmdletBinding()]
    param($a)
    process {
        Write-Host Current pipeline item: $_
    }
}

В таком виде функция не заработает уже. Дело в том, что в advanced functions вы обязаны использовать конструкцию param() для определения аргументов, которые эта функция принимает. Причём, если функция не принимает никаких внешних аргументов, а принимает только данные из конвейера вы всё равно должны это отразить в конструкции param().

function EnumItems {
[CmdletBinding()]
    param([Parameter(ValueFromPipeline = $true)]$a)
    process {
        Write-Host Current pipeline item: $a
    }
}

Теперь можно запускать функцию: 1..5 | EnumItems

Зато в стадии Process (которая запускается для каждого элемента в конвейере) вы теперь можете совершенно невозбранно использовать не $_, а нормальное имя переменной, которая принимает значения из конвейера. Это делает функцию более читабельной. А что с остальными? Try {} Catch {}, trap {}, Foreach-Object {}? В этих конструкциях для обозначения текущего элемента конвейера используется закорючка $_.

• PowerShell 3.0

Для улучшения (или упрощения) понимания сути переменной $_ в PowerShell 3.0 сделали алиас для неё — $psitem. $psitem можно использовать абсолютно везде, где вы можете использовать $_:

1..5 | ForEach-Object {$psitem}
function DivideByZero {
    try {1/0}
    catch {Write-Host $psitem}
}

Да, в catch {} можно использовать переменную $_ или $psitem, которая представляет собой текущий элемент ошибки — $error[0]. Или ещё вот:

switch (1..5) {
    1 {$psitem}
}

В конструкции switch тоже можно использовать $_, или $switch.current, или $psitem , которые представляют одно и то же — текущий элемент энумератора.

Часть 2 — атрибуты переменных

Вернёмся к истории. Во времена PowerShell 1.0 мы писали какие-то интерактивные функции, которые требовали ввода каких-то данных пользователем и внутренняя логика функции что-то с ними делала. Но пользователи (включая администраторов и разработчиков этой функции) — существа доволно-таки, неблагодарные и всегда наровят что-нибудь поделить на ноль и, в конечном итоге, всё сломать. Всё что угодно, лишь бы не работать. Для этого в первых функциях приходилось писать кучу бессмысленного кода, который выполнял одну задачу — проверить, что пользователь ввёл те данные, которые функция ожидает получить. Например, пользователь должен указать хоть какие-то аргументы, а не просто выполнить функцию без указания каких-либо данных. Например, если параметр работает с числами, функция должна быть защищена от пользователя-вредителя, который обязательно в параметр укажет строку, а не число и многое другое. В PowerShell 1.0 создание защиты от дураков и прочих вредителей было не самым простым делом.

В PowerShell 2.0 коварные разработчики PowerShell (с Джефри Сновером во главе отряда) придумали advanced functions. Это позволило писателям функций резко повысить свою производительность за счёт более продвинутых средств борьбы с анонимусомвредителями. Для этого в параметрах функции можно указывать более конкретные фильтры для принимаемых данных. Вот пример:

function Foo {
[CmdletBinding()]
    param(
        [Parameter(Mandatory = $true)]
        [ValidateCount(1,7)]
        [ValidatePattern("Bad|Locked|Missed|New|Ok|Total|Unknown")]
        [String[]]$show
    )
}

Если оградить параметр вот такими атрибутами, пользователь будет вынужден:

1. Обязательно указать значение параметра;
2. В значения параметра указывать только что-то, что указано в ValidatePattern;
3. Значений параметра может быть от 1 до 7.

Вот что мы получим, если не будем соблюдать эти требования:

На любую попытку обмануть функцию, она ответит вам кучей красного текста (видимо, намекает на кровавую расправу). Теперь, в PowerShell 3.0, эти атрибуты можно использовать не только в секции param() функций, но для любых переменных в консоли:

И последнее про атрибуты. Для булевых атрибутов теперь не обязательно указывать $true, например:

function Foo {
[CmdletBinding()]
    param(
        [Parameter(Mandatory, ValueFromPipeline)]
        [int]$a
    )
    process {$a}
}

На сегодня это всё.

Всем желающим уже давно доступна для скачивания клиентская версия Windows 8 (Windows Developer Preview downloads), а подписчикам MSDN доступна и серверная версия — Windows Server 8. Я не буду говорить про все новшества новых систем, потому что мой бложек не выдержит столько ненависти в адрес Microsoft. Но как минимум одна вещь доставляет позитива — Windows PowerShell 3.0 и модули.

Возьмём некоторый типовой Windows Server 2008 R2 и посмотрим на встроенные модули, которые доступны «искаропки»:

совсем не густо — только 7 штук. А вот список модулей в Windows Server 8:

61 модуль!!!!1111одинодин (мой PKI модуль не в счёт). И это не считая тех, которые устанавливаются вместе с ролями сервера (как, например, модуль ServerBackup). Конкретно сейчас говорить об их возможностях ещё рано, потому что они функционально пока не готовы. Но мы можем представить себе, что это всё дружно заработает ближе к RTM. Из наиболее интересных вещей хочется обрать внимание на вот какие модули:

• SmbShare

что сильно намекает на то, что мой модуль ShareUtils прожил яркую, но короткую жизнь. Начиная с релиза Windows 8 проку от него особо не будет.

• PKIClient

ВНЕЗАПНО!!! Команда пкитима (Windows PKI team), издавна прославляющая религиозно правильный certutil.exe и люто-бешено отрицающая PowerShell снизошла до того, чтобы доставить и свои (поверьте, он там не один!) модули в Windows 8. Или, как вариант, получили хороший нагоняй от Джефри Сновера. Windows PKI представлен двумя модулями — клиентским и серверным. Клиентский модуль представлен следующими командами:

Поскольку я немного разбираюсь в PKI и PowerShell, состав этого модуля меня несколько смутил, удивил, оздачил, загнал в тупик. Например, зачем было делать 2 отдельных командлета для экспорта и импорта сертификатов (один для простых сертификатов, другой исключительно для pkcs#12). Что делает Switch-Certificate для меня осталось загадкой. Кстати говоря, командлет Get-Certificate делает совсем не то, что вы подумали. Этот командлет выполняет энроллмент (запрос) сертификата. Всё-таки:

Вобщем, на текущий момент модуль радует, но не впечатляет (если что, я вам не говорил, что 70% функционала модуля не работает вообще).

• CertificateServicesCmdlets

Серверный модуль предназначен для управления службами сертификатов — Active Directory Certificate Services (ADCS). Когда я увидел модуль, чуть не описался от радости. Но заглянув в модуль моё лицо изобразило очень сложное выражение, похожее на постиранную радугу. Я не знаю, как выглядит постиранная радуга, но выглядит модуль примерно так:

на сегодняшний день ни о каком управлении ADCS говорить не приходится, просто набор командлетов для установки/удаления компонентов ADCS. Однако, на удивление некоторые командлеты продуманы достаточно хорошо и даже работают! Т.е. функционально они будут очень полезны. С другой стороны, они оставили мне место для моего PowerShell PKI модуля. Разочаровывают 3 вещи:

1. Get-SSLCertificates — за такое можно смело лупить ножкой от стула. Потому что минздравСновер не одобряет использование названий командлетов во множественном числе.
2. Тот же get-SSLCertificates куда-то потерял свой префикс.
3. Команда Windows PKI решила посоревноваться в специальной олимпиаде с командой Active Directory на самое длинное название командлета:

И ни одного алиаса! Пока что Windows PKI впереди на 3 символа:

Но мы поддержим команду Active Directory и обвиним команду Windows PKI в том, что у последних префикс на 2 символа длиннее (AD против ADCS), т.е. в итоге превосходство в 1 символ. Кому же достанется первый приз? :) Но мы поддержим обе команды и узнаем победителя с релизом Windows Server 8 :)

В пост про модули я хочу рассказать и про новую возможность автозавершения команд в PowerShell 3.0: при импорте модуля вы можете набрать Import-Module, нажать <tab> и tab expansion будет автозавершать имена модулей. Т.е. вам достаточно знать 1-2 первые буквы названия модуля и он у вас в кармане ;)

На сегодня всё. В следующий раз я постараюсь рассказать ещё что-нибудь интересное про PowerShell 3.0.

Disclaimer: данный обзор проводится по Dev Preview редакции Windows 8. Это даже не CTP и не Beta, поэтому любой функционал в финальной версии может быть изменён, добавлен или удалён.

В новой версии PowerShell появился и не менее новый (ВНЕЗАПНО) редактор или IDE для разработки скриптов PowerShell. По некоторым данным, новый PowerShell ISE это самый настоящий повергуикапец. И вот почему. Например, первый запуск ISE:

Начнём с того, что мы видим. А видим сразу мы панель Commands, которая показывает список доступных командлетов. Так же, можете фильтровать их по модулям и по именам. Причём, поиск интерактивный. Но смысл этой панельки совсем не в том, чтобы просто показать какие командлеты у нас доступны, а больше:

Как видно, в этой панели есть графическая набиралка параметров. Вы можете заполнить параметры как нужно и потом с ними что-нибудь сделать. В параметры можно подавать массивы строк, разделяя их запятой (как и в обычной консоли). Например, если нажать кнопку Insert, соответствующая команда PowerShell (вместе с параметрами и аргументами) будет вставлена в панель консоли ISE (показано на скриншоте). Кнопка Copy копирует эту же строку в буфер обмена, так что вы можете её вставить в панель редактора. Так же можно заметить, что вы можете использовать разные наборы параметров (parameter set). Эта панелька будет интересна скорее новичкам, потому что все параметры на виду и кавычки будут проставлены автоматически. Но эта панелька может быть полезна и для не новичков, потому что:

Количество встроенных командлетов в PowerShell V2:

и в PowerShell 3.0:

Почти в три раза больше и вполне можно затеряться в них.

А теперь, самый эпиквин:

Наконец-то появился вменяемый Intellisense! По кнопке [Tab] в редакторе автозавершаются имена переменных! Но есть один нюанс: прежде чем автозавершать имена переменных, код, в котором используется переменная должен быть запущен. Вариант, как в PowerGUI Script Editor'е (когда имена переменных в Intellisense появляются сразу, как они упоминуются в редакторе) пока что не работает. Ну и Intellisense для переменных пока что не предусмотрен, только табом переключать. Intellisense так же доступен для извлечения членов классов:

Единственное, для чего не работает Intellisense: стандартные операторы (-eq, –ne, –like, –notlike, etc.) и классы .NET'а. Но это тоже должно появиться в будущем.

А вот здесь мы видим много интересного. В ISE появился outlining, т.е. можно сворачивать всякие конструкции (нажимая плюсики и минусики). И ещё появился онлайн парсер кода и если парсер видит что-то непотребное, он будет весьма недоволен и подчёркивать красной волнистой линией. Если навести курсор на неё, вылезет тултип (tooltip) c описанием ошибки. Я немного забежал вперёд и спалил новый параметр для цикла foreach: –parallel. Сейчас он не реализован, но обязательно будет в финальной версии. Суть всего этого — теперь цикл будет работать не последовательно, а параллельно! Я считаю это винрарным улучшением перформанса.

Вроде мелочь, а приятно! Теперь ISE показывает парные скобки (круглые, квадратные, фигурные), кавычки (одиночные, двойные, herestrings).

В ISE теперь есть сниппеты :) И наконец-то поправили кодировку файлов с Unicode Big Endian (что доставляло немало лулзовкирпичей при запуске такого скрипта в консоле) на UTF8.

Если подвести краткий итог, PowerShell ISE сделал серьёзную заявку на право называться редактором для PowerShell. Причём, при определённых условиях (в зависимости от конечного функционала) ISE может стать моим основным редактором, даже не смотря на многолетнюю привычку использовать PowerGUI Script Editor. В любом случае, для новичков ISE будет хорошим стартом.

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

Итак, на днях в открытый доступ выложили Windows Management Framework 3.0 CTP (Community Technology Preview), который содержит и PowerShell 3.0 (очевидно, что тоже ещё в стадии CTP). WMF3 устанавливается на системы Windows 7 и Windows Server 2008 R2. Владельцы других систем пока могут быть свободны. Краткий список нововведений есть на странице загрузки. Если у вас есть предыдущая версия WMF 3.0 (KB2508781 и KB2506143), её надо будет удалить, иначе возможны разные сюрпризы. И ещё раз ссылка для самых розовых:

>> Windows Management Framework 3.0 CTP <<

На этом пока всё. А в следующих разах расскажу про что-нибудь новое подробнее и как и почему случился повергуикапец :)