Vadims Podans's blog - Полезности

Add-PSSnapin и PowerGUI

Camelot — Fri, 16 Oct 2009 17:18:19 GMT

Знаете ли вы как подключать 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 Powered - http://www.sysadmins.lv

PowerShell ISE vs PowerGUI

Camelot — Sat, 03 Oct 2009 15:19:24 GMT

Когда пользователь начинает работать с 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

Примечание: последнее изменение таблицы 16.03.2010

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

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

PowerShell Powered - http://www.sysadmins.lv

Различия между Share Permissions и NTFS Rights

Camelot — Mon, 24 Aug 2009 21:13:44 GMT

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 и фактически их содержит не в текстовом виде, а в числовом. Вот как выглядят числовые сопоставления текстовым правам:

[↓] [vPodans] ([system.enum]::getnames([System.Security.AccessControl.FileSystemRights])) | %{@{$_ = ([System.Securit
y.AccessControl.FileSystemRights]"$_").value__}}

Name                           Value
----                           -----
ListDirectory                  1
ReadData                       1
WriteData                      2
CreateFiles                    2
CreateDirectories              4
AppendData                     4
ReadExtendedAttributes         8
WriteExtendedAttributes        16
Traverse                       32
ExecuteFile                    32
DeleteSubdirectoriesAndFiles   64
ReadAttributes                 128
WriteAttributes                256
Write                          278
Delete                         65536
ReadPermissions                131072
Read                           131209
ReadAndExecute                 131241
Modify                         197055
ChangePermissions              262144
TakeOwnership                  524288
Synchronize                    1048576
FullControl                    2032127


[↓] [vPodans]

Как видно из таблички, 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):

[↓] [vPodans] ([System.Security.AccessControl.FileSystemRights]"Modify, Synchronize").value__
1245631

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

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

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

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

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

PowerShell Powered - http://www.sysadmins.lv

Список блогов PowerShell MVP

Camelot — Thu, 04 Jun 2009 21:43:12 GMT

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

MVP Name	Blog Name	Blog language
/\/\o\/\/	ThePowerShellGuy	English
Arnaud Petitjean	PowerShell Scripting	French
Brandon Shell	BS on PoSH	English
Charlie Russel	x(perts)64	English
Daisuke Mutaguchi	Scripting Weblog	Japanese
Dmitry Sotnikov	PowerShell and beyond	English
Don Jones	Concentrated Technology	English
Doug Finke	Development in a Blink	English
Gu Huajun	ghjconan's blog	Chinese
Guy Thomas		English
Hal Rottenberg	TechProsaic	English
Hiroki Takahashi	HIRO’s.NET	Japanese
Hiroshi Yoshioka	PowerShell Memo	Japanese
Jeffrey Hicks	Scripting Blog and More	English
Karl Prosser	Live PowerShell	English
Keith Hill	Keith Hill’s Blog	English
Kirk Munro	Poshoholic	English
Marco Shaw	Get-PowershellBlog	English
Max Trinidad	Florida PowerShell User Group	English
Oisin Grehan	Nivot Ink	English
Richard Siddaway	Richard Siddaway’s Weblog	English
Shay Levy	$cript Fanatic	English
Sherif Talaat	The Arabian PowerShell	Arabic
Tobias Weltner	Dreaming in PowerShell	English
Vadims Podans	PowerShell Powered	Russian
Vasily Gusev	PowerShell и другие скрипты	Russian
Vinicius Canto	e a arte de criar scripts	Portuguese
Ying Li	PowerShell & System Center	English

Удачи! © One

PowerShell Powered - http://www.sysadmins.lv

PowerGUI 1.6

Camelot — Thu, 08 Jan 2009 17:04:29 GMT

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

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

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

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

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

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

PowerShell Powered - http://www.sysadmins.lv