Contents of this directory is archived and no longer updated.

Posts on this page:

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

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

Powershell Snapins and Modules in PowerGUI

В окне натыкать галочек и/или кнопкой 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. Вот как это может выглядеть:

PowerGUI IntelliSense support

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

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

PowerGUI ToolTips

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

  • Multiple runspaces

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

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

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

$psISE.CurrentFile.Save([Text.Encoding]::UTF8)
  • Исполнение сохранённых скриптов и Execution Policy

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

The script you are about to run will be saved 
Т.е. он сохраняет файл и пытается его запустить. В 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 :yes: :no: :no:
Is free :yes: :yes: :no:
Fast start :no: :no: :no:
Powershell Support 100% <100% <100%
External PowerShell window :yes: :yes: :yes:
Remote PowerShell tab :yes: :no: :no:
IntelliSense :no: :yes: :yes:
Multiple Runspaces :yes: :yes: :no:
ToolTips :no: :yes: :yes:
Syntax highlighting :yes: :yes: :yes:
Error syntax highlighting :no: :yes: :yes:
Error autocorrection :no: :no: :yes:
Changed lines highlighting :no: :yes: :yes:
Outline support :no: :yes: :yes:
Support for signing :no: :yes: :yes:
Can sign within IDE :no: :no: :yes:
Run signed scripts in external window :yes: :no: :yes:
Readable command help :yes: :yes: :yes:
Configurable editor panes :yes: :yes: :yes:
Variable pane :no: :yes: :yes:
PS $Profile support :no: :yes: :yes:
BreakPoints :yes: :yes: :yes:
Code templates :no: :yes: :yes:
Print from editor :no: :yes: :yes:
Script autosave :no: :yes: :yes:

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

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

[↓] [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

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

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 - PowerGUI. Версии 1.5.x.x не были совместимы с PowerShell V2 CTP3, но теперь это поправлено:

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

pgui3

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

 

pgui1

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

pgui2

pgui3

pgui4

pgui5

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

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