Знаете ли вы как подключать IntelliSense к новым командлетам, которые появляются после подключения оснастки? Например, в консоли PowerShell вы подключаете оснастку Windows.ServerBackup и сразу получаете доступ к новым командлетам. В PowerGUI, к сожалению, после подключения оснастки через Add-PSSnapin или Import-Module новые командлеты начинают работать при отладке, но без подсветки и прочих красивостей блондинка-стайл. Мне потребовалось несколько часов, чтобы узнать, в чём тут дело. Из них минут 10 заняла переписка с командой разработчиков PowerGUI (угу, я иногда злоупотребляю своим положением).

Итак, если вы хотите получать IntelliSense для новых командлетов, которые появляются после подключения оснастки или импорта модуля (Import-Module), то нужно сделать: File –> PowerShell Libraries:

В окне натыкать галочек и/или кнопкой Add Module добавить модуль/модули и тогда появится IntelliSense и прочие побочные принадлежности в самом редакторе.

Have fun with a script writing with PowerGUI!

Когда пользователь начинает работать с PowerShell, то со временем перед ним возникает вопрос — какой редактор (вернее сказать, среду разработки) выбрать? Решений уже достаточно много, чтобы было из чего выбирать:

• PowerShell ISE
• PowerGUI
• PrimalScript
• PowerShellPlus
• …

в большинстве случаев выбор делают между первыми двумя продуктами. Иногда споры об этом переходят в разряд религиозных войн. Истинные фанаты PowerShell выбирают ISE. В принципе, как просто редактор он вполне неплох, т.к. уже есть в коробке (начиная с первых CTP версий PowerShell V2) и для работы с ним никаких телодвижений делать не надо. Однако с ним есть ряд трудностей:

• IntelliSense

В ISE отсутствует IntelliSense (автозавершение команд и свойств/методов объекта). А это весьма необходимая функция в среде разработки. Мне кажется, что это поняли уже все, кроме разработчиков PowerShell ISE. Вот как это может выглядеть:

• Подсказки (ToolTips)

При наведении курсора на команду, не отображаются подсказки (Tooltips). В PowerGUI это выглядит действительно классно, точь-в-точь как в Visual Studio:

Причём, на этой картинке можно нажимать на стрелочки вверх/вниз для просмотра типов данных, которые принимаются в качестве аргумента. При наведении на переменную PowerGUI показывает даже тип и содержимое переменной (в разумных пределах).

• Multiple runspaces

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

• Кодировка сохраняемых файлов

ISE по умолчанию сохраняет файлы в Big Endian кодировке. Вроде бы ничего криминального, но... Set-Authenticodesignature не умеет подписывать скрипты в Big Endian кодировке! Поэтому вы не сможете подписать штатными средствами ни один скрипт, который был сохранён в ISE! Для этого нужно прибегать к грязным хакам. Т.е. использовать такую строку, которая переопределит кодировку, в которой скрипт будет сохранён:

$psISE.CurrentFile.Save([Text.Encoding]::UTF8)

• Исполнение сохранённых скриптов и Execution Policy

Вы можете в нём исполнять свой сценарий до тех пор, пока не сохраните его в файл. А вот когда вы редактируете уже сохранённый скрипт, то получаете бонус в виде того, что скрипт не будет исполняться внутри ISE, если у вас политика исполнения скриптов выставлена в AllSigned. ISE об этом честно предупреждает:

 
Т.е. он сохраняет файл и пытается его запустить. В PowerGUI сделано куда более гуманно. Из основного редактора код условно копируется и вставляется в консоль PowerShell. Т.е. вы можете спокойно редактировать и отлаживать свой скрипт и только когда он будет готов к работе — подписывать скрипт. В случае с ISE вам придётся либо после каждого изменения сохранять и переподписывать скрипт (а это дико неудобно), либо выделять весь код и выбирать Run Selection. А это тоже не очень удобно. Плюс, сохранение скрипта перед исполнением ведёт к другой проблеме. Вы не сможете отменить изменения на более раннее состояние.

• Поддержка профиля $Profile

В ISE вы не можете использовать свой профиль (который в консоли содержится в переменной $Profile), а только поддерживать дополнительный профиль, который находится в той же папке, что и основной, но под именем Microsoft.PowerShellISE_profile.ps1

• Отслеживание изменений в файле

ISE не поддерживает проверку файла на изменения, хотя это должно быть удобно. Я часто редактирую свои файлы дома на нотебуке и на работе. Папка со скриптами синхронизируется между домом и работой через Live Sync. Я достаточно редко закрываю редактор, поэтому вечером сохраняю файл (который уже открыт в редакторе на работе) и всё. Утром, придя на работу я могу без переоткрытия файла могу продолжать его редактировать. PowerGUI просто сообщит, что файл был изменён и сам предложит загрузить последнюю сохранённую версию. С ISE придётся вручную переоткрывать файл.

• About

Я не могу вспомнить программ, которые бы имели меню Help, но внутри не имели подменю About. но это просто мелочи уже, которые не влияют на удобство разработки скриптов.

Updated 04.10.2009

Если подвести это всё в табличку, то получится примерно так:

	PowerShell ISE	PowerGUI	PowerShell Plus
Built-In
Is free
Fast start
Powershell Support	100%	<100%	<100%
External PowerShell window
Remote PowerShell tab
IntelliSense
Multiple Runspaces
ToolTips
Syntax highlighting
Error syntax highlighting
Error autocorrection
Changed lines highlighting
Outline support
Support for signing
Can sign within IDE
Run signed scripts in external window
Readable command help
Configurable editor panes
Variable pane
PS $Profile support
BreakPoints
Code templates
Print from editor
Script autosave

Вобщем, я обозначил те вещи, которые я хотел бы видеть в хорошем редакторе. И значительное большинство моих хотелок уже есть в PowerGUI. О достоинствах PowerGUI можно говорить сколько угодно, но не буду смущать Диму Сотникова, поэтому скажу, что их продукт очень крутой. Но, в то же время, есть к чему стремиться.

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

Disclaimer: данный пост несёт исключительно теоретическую ценность. Никакой практической пользы от него вы не получите.

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

Как известно, при доступе к общим ресурсам (сетевым папкам) мы различаем 2 типа прав:

• Share Permissions
• NTFS Rights

Оба типа прав влияют на результирующие (эффективные) права пользователя при доступе к сетевому ресурсу. В общем смысле эффективные права будут являть собой наиболее ограничивающее разрешение из обоих типов прав. Например, на ресурс установлено право Share Permissions = Read, а NTFS = Full Control, то исходя из наиболее ограничивающего разрешения эффективным будет Read. Если Share Permissions = FullControl, а NTFS = Modify, то эффективным правом для пользователя будет Modify. Вот такая несложная схема. Т.е. там, где прав меньше, те и будут ваши Как известно, эта проблема редко кого касается, т.к. обычно на уровне Share Permissions выдают FullControl на ресурс и дальше уже права регулируют за счёт NTFS. Как бы всё правильно, но если раскопать вопрос глубже, то появляются интересные моменты.

http://technet.microsoft.com/en-us/library/cc784499(WS.10).aspx – по этой ссылке можно найти сопоставление Share Permissons с NTFS Rights. Такое сопоставление удобно тем, что рассчитывать оба типа прав можно с использованием одних и тех же классов .NET, без необходимости городить отдельные библиотеки и классы для управления списками доступа ACL. Грубо говоря, фактическое сопоставление выглядит вот так (по схеме Share Permission = NTFS Right):

• Read = ReadAndExecute
• Change = Modify + DeleteSubfoldersAndFiles
• FullControl = FullControl

Но это в общем смысле. Внутри Windows это выглядит чуть сложнее, т.к. там появляется хитрое право Synchronize. Т.е. таблица уже имеет такой вид:

• Read = ReadAndExecute + Synchronize
• Change = Modify + DeleteSubfoldersAndFiles + Synchronize
• FullControl = FullControl (в обоих случаях Synchronize уже включено).

Обратите внимание на наличие DeleteSubfoldersAndFiles в Change. Windows оба этих типа прав рассчитывает через класс .NET – FileSystemRights и фактически их содержит не в текстовом виде, а в числовом. Вот как выглядят числовые сопоставления текстовым правам:

Как видно из таблички, FullControl является суммой всех перечисленных прав. Давайте разберём, что такое Modify, т.е. какие права нужно иметь для получения этого Modify:

• ListFolder - 1
• CreateFiles - 2
• Createfolders(Directories) - 4
• ReadExtendedAttributes - 8
• WriteExtendedAttributes - 16
• Traverse - 32
• ReadAttributes - 128
• WriteAttributes - 256
• Delete - 65536
• ReadPermissions – 131072

В этом легко убедиться, т.к. если мы сложим все эти цифры, то получим 197055 (как и отражено в таблице). Обратимся к ссылке: http://vpodans.spaces.live.com/blog/cns!BB1419A2CFC1E008!170.entry.

Теперь нам нужно преобразовать права доступа в класс FileSystemRights. Преобразование типа прав так же было ранее мною описано в первой части Управление ACL в PowerShell. Пара слов о том, чем отличаются права Read, Change и Full Control в контексте разрешений сетевого ресурса от контекста разрешений NTFS. Этим правам в NTFS сопоставляются Read + Execute, Modify и Full Control соответственно и плюс право Synchonize. Поэтому давайте запишем маску доступа в переменную $ace:

$ace.AccessMask = [System.Security.AccessControl.FileSystemRights]"Modify, Synchronize"

Чтобы получить Change, нам достаточно к этому числу (197055) прибавить Synchronize (1048576):

Вот это в понимании SecurityDescriptor является эквивалентом нашего Change. Но я чуть ранее просил вас обратить внимание на наличие DeleteSubfoldersAndFiles в Change. Но тут его уже всунуть просто некуда, т.к. 1245695 (это число получится, если к Modify прибавить Synchronize и DeleteSubfoldersAndFiles) не будет распознано SecurityDescriptor’ом в методе SetShareInfo, как валидное число.

Иными словами, что у нас получается:

1) Change в понимании фактических прав является суммой: Modify + DeleteSubfoldersAndDiles + Synchronize

2) Change в понимании .NET является суммой: Modify + Synchronize

И чем вызвано такое несоответствие мне неизвестно. Но в качестве теоретической справки это может быть полезным.

Hal Rottenberg и Shay Levy сегодня собрали список блогов всех действующих MVP по PowerShell. Думается, что это будет весьма полезный для многих список, в котором любители PowerShell могут массу наиполезнейшей информации. Итак, вот список:

Удачи! © One

Наверное, не все ещё знают, что вчера состоялся очередной релиз графического редактора для PowerShell - PowerGUI. Версии 1.5.x.x не были совместимы с PowerShell V2 CTP3, но теперь это поправлено:

• полная поддержка PowerShell V2 CTP3

• можно теперь переставлять панели (как в Visual Studio), откреплять и прикреплять, вобщем настраивать как вам нужно.

• панель инструментов теперь молностью настраиваемая. Так же можно назначать горячие клавиши для каких-то действий:

• и дебаггер теперь умеет переходить во внешние скрипты. Из актуального вроде всё. Ну и ссылка на страницу закачки PowerGUI:

[нажать на паровозик ]