Windows PowerShell: Курс выживания при создании сценариев

Больше людей привыкают к работе с Windows PowerShell и начинают обдумывать достоинства этой технологии. В связи с этим этот выпуск рубрики будет длинноватым. Мы очень кратко пробежимся по базисным элементам Windows PowerShell, в том числе узнаем, как создавать параметризованные сценарии. В следующих выпусках я сосредоточусь на определенных темах, базирующихся на материале, изложенном в нынешней статье.

Если вы не привыкли к выполнению команд Windows PowerShell в консоли, так как это кажется вам очень сложным, пусть это и тяжело, все равно попробуйте освоить их. Нужно иметь не плохое представление о функциях безопасности Windows PowerShell. Вы должны знать о политике выполнения и о том какие характеристики вы используете. Если вы еще не понимаете разницу меж RemoteSigned и AllSigned, также почему одна из этих политик может быть лучше другой, вероятнее всего вы не готовы к чтению нижеследующего материала.

Вы также должны знать, как делать сценарии в оболочке, также держать в голове, что при выполнении сценария всегда необходимо указывать путь и название файла. В конце концов, вы должны осознавать, в чем разница при выполнении в среде ISE (Integrated Scripting Environment) и в консоли. В ISE сценарии производятся в глобальном контексте. В обыкновенной оболочке консоли у сценариев обычно свой контекст. Я расскажу о контексте, но вы уже должны хотя бы приблизительно осознавать, что он значит и что делает.

Если вам кажется, что вы недостаточно подготовлены, могу порекомендовать почитать мою книжку «Learn Windows PowerShell in a Month of Lunches» (Manning Publications, 2011) и сайт по теме, — может быть эти ресурсы посодействуют вам усвоить больше базисной инфы.

Сможете воспользоваться этими ресурсами в процессе чтения статьи. Попробуйте выполнить примеры. Если ввести (либо скопировать) примеры сценариев в среду Windows PowerShell ISE, начиная со строчки, тогда номера строк будут совпадать с номерами строк в описаниях.

Файлы сценариев Windows PowerShell

Файл сценария Windows PowerShell представляет собой обычной текстовый файл с расширением .PS1. Единица показывает на версию не Windows PowerShell, а быстрее версию обработчика языка. В Windows PowerShell версий 1 и 2 употребляется обработчик языка версии 1. Потому обе версии оболочки инсталлируются в подпапку v1.0 папки WindowsSystem32WindowsPowerShell.

Сценарий Windows PowerShell не совершенно похож на командный файл для командной строчки, не считая того выполнение сценария не совершенно то же самое, что вводить вручную те же команды в той же последовательности. К примеру, откройте окно консоли и сделайте последующее, нажимая Enter после каждой строчки:

Get-Service
Get-Process

А сейчас введите вточности такие же команды в файл сценария либо в панель редактирования сценариев в ISE и сделайте сценарий. Результаты будут отличаться. При каждом нажатии Enter в Windows PowerShell вы запускаете новый сборочный поток. Все вводимые вами команды производятся в одном конвейере. В конце существования сборочного потока Windows PowerShell конвертирует его содержимое в текст на дисплее. При выполнении этих 2-ух команд в обыкновенной консоли это происходит в 2-ух различных конвейерах.

Windows PowerShell смогла сделать уникальные результаты работы для каждого набора выходных данных. С другой стороны, при запуске в составе сценария обе команды производятся в одном конвейере. Система форматирования Windows PowerShell не так утонченна, чтоб создавать отдельные наборы выходных данных для 2-ух результатов. Попробуйте выполнить это в консоли:

Get-Service;Get-Process

Результаты будут такими же, как и при выполнении сценария с этими 2-мя командами. В этом случае обе команды производятся в одном конвейере. Конкретно это происходит при выполнении сценария.

Практический вывод из всего может заключаться в том, что сценарий должен возвращать выходные данные только 1-го вида. Это нехорошая мысль из-за ограничений системы форматирования. Есть также другие суждения. Не надо, чтоб сценарий сразу сбрасывал в сборочный поток разнородные данные.

Нужно держать в голове об этом правиле в протяжении всего времени чтения этой статьи. Сценарий должен создавать один и только один тип выходных данных. Единственное исключение — когда сценарий употребляется как репозиторий нескольких функций. В данном случае любая функция должна генерировать один и только один тип выходных данных.

Переменные

Переменные следует считать кое-чем вроде ящика, в который можно положить одну либо несколько вещей, даже разнородных. У ящика есть имя, и в Windows PowerShell это имя может содержать фактически любые знаки. Именованием переменной может быть как «Var», так и «{my variable}». Во 2-м примере имя переменной заключено в фигурные скобки, так как оно содержит пробелы; смотрится это не очень прекрасно. Рекомендую все-же использовать в именах переменных только буковкы, числа и подчеркивания.

При использовании имени переменной ссылаются на сам «ящик». Если необходимо сослаться на содержимое ящика, используйте символ бакса, к примеру, так: $var. В Windows PowerShell вам нередко будут встречаться переменные со знаком бакса, потому что весь смысл в его использовании заключается в получении содержимого переменных. Совместно с тем, нужно держать в голове, что символ бакса не является частью имени переменной. Это всего только подсказка для Windows PowerShell, что вам требуется содержимое, а не сам ящик. Вот несколько примеров:

$var = ‘hello’
$number = 1
$numbers = 1,2,3,4,5,6,7,8,9

В примерах показано, как назначать переменным значения с внедрением оператора присвоения (=). В последнем примере создается массив, так как Windows PowerShell интерпертирует разбитые запятыми списки как массивы, либо наборы частей. В первом примере присваивается объект, представляющий из себя строчку, а вся строчка заключается в кавычки.

Есть одна особенность Windows PowerShell, которая может вводить в заблуждение новичков. Windows PowerShell не «понимает», какой смысл связывается с именованием переменной. Имя $computername не «говорит» оболочке, что в переменной хранится имя компьютера.

Аналогично имя $numbers не гласит оболочке, что переменная будет содержать более 1-го числа. Оболочке также все равно, какое число вы используете, — единственное либо множественное. Для оболочки последующее выражение:

$numbers = 1

…правильное и ничем не отличается от такового:

$numbers = ‘fred.’

Вкупе с тем, если переменная содержит несколько значений, для получения 1-го из их можно использовать особый синтаксис. Чтоб получить 1-ый элемент, необходимо использовать выражение $numbers[0], 2-ой — $numbers[1], а последний элемент изображается так: $numbers[-1], предпоследний — $numbers[-2] и т.д..

Кавычки

Для выделения переменных рекомендуется использовать одинарные кавычки, если только нет особенных обстоятельств использовать другой синтаксис. Есть три ситуации, в каких лучше использовать двойные кавычки.

Во-1-х, это делают, когда необходимо воткнуть содержимое переменной в строчку. Только при наличии двойных кавычек Windows PowerShell будет находить символ «$» и полагать, что все, что следует после чего знака и до первого знака, который не может быть частью имени переменной, является именованием переменной. Заместо знака бакса с именованием переменной будет вставлено ее содержимое.

$name = ‘Don’
$prompt = «My name is $name»

Переменная $prompt содержит строчку «My name is Don», так как $name заменяется содержимым этой переменной. Это превосходный прием — соединение строк заместо их конкатенации.

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

$debug = «`$computer contains $computer»
$head = «Column`tColumn`tColumn»

В первом примере 1-ый символ бакса $ отменяется. Оборотная кавычка отменяет его значение как аксессора переменной. Если переменная $computer содержит строчку «SERVER», тогда в $debug будет содержаться такая строчка: «$computer contains SERVER».

Во 2-м примере «`t» представляет собой знак табуляции, потому Windows PowerShell расположит меж словами Column знаки табуляции. Подробнее об управляющих знаках см. интернет-страницу.

В конце концов, двойные кавычки употребляются, когда строчка должна содержать одинарные кавычки:

$filter1 = «name=’BITS’»
$computer = ‘BITS’
$filter2 = «name=’$computer’»

В этом примере создается строчка «name=’BITS’». Все нужное заключается в двойные кавычки. В $filter1 и $filter2 содержится одно и то же, но в $filter2 значение задается с внедрением уловкой с подменой переменной в двойных кавычках. Заметьте, что значение имеет только самая «внешняя» пара кавычек. Одинарные кавычки оболочку Windows PowerShell не заинтересовывают. Эти одинарные кавычки представляют собой обыкновенные литеральные знаки. Windows PowerShell их не интерпретирует.

Члены и переменные объектов

В Windows PowerShell все состоит из объектов. Даже обычная строчка, такая как «name», является объектом типа System.String. Чтоб выяснить тип объекта (другими словами, что представляет собой объект), также его членов, к которым относятся его характеристики и способы, довольно передать объект в Get-Member по сборочному потоку:

$var = ‘Hello’
$var | Get-Member

Используйте точку после имени переменной, чтоб сказать оболочке: «Мне не нужен доступ ко всему объекту в переменной, а только к одному из его параметров либо методов». После точки укажите необходимое свойство либо имя способа.

После имен способов всегда следует пара скобок. Некие способы принимают аргументы, которые указываются в скобках, отделенные запятыми. Другим способам аргументы не необходимы, потому скобки пустые, но они непременно должны быть:

$svc = Get-Service
$svc[0].name
$name = $svc[1].name
$name.length
$name.ToUpper()

Направьте внимание на вторую строку. Она начинается с воззвания к первому элементу переменной $svc. Точка значит, что нам не нужен весь объект, а только его свойство либо способ. В этом случае необходимо свойство name. В пятой строке показано, как обращаться к способу, указывая его имя после точки, также пару скобок.

Обычно точка в именах переменных не употребляется, потому что она отделяет свойство либо способ. Это значит, что 2-ая строчка в последующем примере будет делать не то, что ожидалось:

$service = ‘bits’
$name = «Service is $service.ToUpper()»
$upper = $name.ToUpper()
$name = «Service is $upper»

На 2-ой строке $name содержит«Service is BITS.ToUpper()», а в четвертой строке — «Service is BITS».

Скобки

Кроме указания на способы объектов, скобки также служат в Windows PowerShell маркерами, определяющими порядок выполнения, — как в обыденных алгебраических выражениях. По другому говоря, скобки указывают оболочке, что необходимо делать сначала. Выражение в скобках заменяется тем, что выходит в итоге вычисления этого выражения. Вот несколько задачек на сообразительность:

$name = (Get-Service)[0].name
Get-Service -computerName (Get-Content names.txt)

В первой строке $name содержит имя первой службы в системе. Чтоб осознать этот пример, придется малость натужить мозги. Начнем с выражения в скобках. Windows PowerShell начнет анализ конкретно с этого места. Get-Service разрешается в набор, либо массив, служб. Выражение [0] позволяет получить 1-ый элемент массива, которым будет 1-ая служба. Потому что за этим следует точка, мы знаем, что идет воззвание к свойству либо способу этой службы, а не ко всему объекту. В конце концов мы извлекаем только имя службы.

Во 2-ой строке выражение в скобках читает содержимое текстового файла. Если файл содержит имена компов — по одному в строке, Get-Content возвратит массив имен компов. Они передаются в параметр –computerName командлета Get-Service. В этом случае оболочка передаст итог хоть какого выражения в скобках, возвращающего массив строк, в параметр –computerName, так как последний сотворен принимать массивы строк.

Область деяния

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

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

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

New-PSDrive -PSProviderFileSystem -Root C: -Name Sys
Dir SYS:

После выполнения сценария вручную сделайте команду Dir SYS:. Вы получите ошибку. Причина в том, что диск SYS: был сотворен в сценарии. По окончании работы сценария все им сделанное было уничтожено. Диск SYS: больше не существует. Не все в оболочке работает в своем спектре. Такие элементы, как модули всегда обрабатываются глобально. Модуль, загруженный сценарием, остается таким по окончании работы сценария.

Если в области деяния предпринимается попытка обратиться к чему-то, что не было сотворено в ней, Windows PowerShell обращается к последующей области деяния более высочайшего уровня («родительской»). Вот почему псевдоним Dir сработал в сделанном вами сценарии. Хотя Dir не существовал в области деяния сценария, он существовал в области деяния более высочайшего уровня — в глобальной области деяния. В области деяния можно создавать элементы с именами, которые есть в области более высочайшего уровня. Вот очередной сценарий для выполнения:

Dir
New-Alias Dir Get-Alias
Dir

Это кажется странноватым, но при первом выполнении Dir каталог не существовал в области деяния сценария. Был применен псевдоним Dir более высочайшего уровня. Этот псевдоним показывает на Get-ChildItem, потому было показано знакомое содержимое каталога.

Потом сценарий сделал новый псевдоним по имени Dir, который уже показывает на Get-Alias. Эта самая команда производилась во 2-м случае. Все это никак не воздействовало на псевдоним Dir верхнего уровня. Попробуйте выполнить Dir в оболочке после пуска предшествующего сценария и вы опять получите перечень содержимого каталога.

В областях деяния в особенности просто запутаться, когда идет речь о переменных. Обычно, из определенной области деяния никогда не нужно обращаться к элементам за ее пределами, в особенности к переменным. Есть синтаксис для выполнения таких операций, к примеру можно использовать $global:var для принудительного воззвания к переменной $var глобальной области деяния, но это очень нехороший метод, применение которого допустимо исключительно в очень специфичных обстоятельствах.

Язык сценариев Windows PowerShell

Windows PowerShell содержит очень облегченный язык сценариев, который состоит наименее чем из 2-ух дюжин слов. Он очень отличается от настоящего языка программирования, такового как VBScript, который содержит практически три сотки слов.

Невзирая на свою простоту, язык Windows PowerShell более чем эффективен для собственных задач. На данный момент я расскажу об главных сценарных конструкциях, но вы всегда сможете получить более подробные сведения, обратившись к соответственной about-статье в оболочке. К примеру, help about_switch содержит информацию о конструкции Switch, а help about_if —о конструкции If. Чтоб получить перечень всех about-статей, сделайте команду help about*.

Конструкция If

Это основная конструкция Windows PowerShell для принятия решений. Полная ее форма смотрится так:

If ($this -eq $that) {
# commands
} elseif ($those -ne $them) {
# commands
} elseif ($we -gt $they) {
# commands
} else {
# commands
}

Ключевое слово «If» является неотклонимой частью конструкции. Итог вычисления последующего за ним выражения должен быть True либо False. Windows PowerShell всегда интерпретирует ноль как False, а хоть какое ненулевое значение как True.

Windows PowerShell также различает интегрированные переменные $True и $False, которые представляют обозначенные булевы значения. Если выражение в скобках равно True, тогда производятся команды в последующих дальше фигурных скобках. Если выражение равно False, эти команды не производятся. Это мало нужный состав конструкции If.

Можно пойти чуток далее, задав один либо больше разделов ElseIf. Они работают так же, как и конструкция If. У их есть собственное выражение в скобках. Если оно равно True, производятся команды в последующих за выражением фигурных скобках. В неприятном случае команды не производятся.

Окончить конструкцию можно блоком Else, который производится, если не выполнился ни один из прошлых блоков команд. Выполнится только 1-ый блок команд, для которого выражение в скобках равно True. К примеру, если $this не равно $that, а $those не равно $them, тогда будут выполнены только команды в четвертой строке. Windows PowerShell даже не станет вычислять выражение для elseif в пятой строке.

Знак «решетка» (#) служит для выделения комментариев, другими словами Windows PowerShell игнорирует весь текст от этого знака до последующего возврата каретки. Также направьте внимание на аккуратное форматирование обрисованных конструкций. Некие форматируют текст так:

if ($those -eq $these)
{
#commands
}

Непринципиально, где расположить фигурные скобки. Но принципиально при всем этом придерживаться 1-го стиля форматирования, чтоб сценарии было просто читать. Также принципиально делать отступы до подходящего уровня каждую строчку в фигурных скобках.

В среде Windows PowerShell ISE для этой цели можно использовать кнопку Tab, при нажатии которой по дефлоту делается отступ размеров в четыре пробела. Отступы в коде — это базисное требование к написанию кода. Если этого не делать, в больших сценариях будет очень трудно не ошибиться при расстановке фигурных скобок. Ну и не стоить гласить, что даже новенькие Windows PowerShell будут глумиться над вашим текстом без отступов. Поглядите на этот плохо форматированный сценарий:

function mine {
if ($this -eq $that){
get-service
}}

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

function mine {
if ($this -eq $that){
get-service
}
}

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

Конструкция Do While

Это конструкция цикла в Windows PowerShell. Она служит для неоднократного выполнения блока команд, пока условие равно True либо не станет True. Вот самый обычный случай:

Do {
# commands
} While ($this -eq $that)

В этом варианте конструкции команды в фигурных скобках выполнятся по последней мере один раз. Условие While рассчитывается не ранее, чем 1-ый раз выполнится блок команд. Можно перенести While — тогда команды будут выполнены, только если с самого начала условие равно True:

While (Test-Path $path) {
# commands
}

Заметьте, что во 2-м примере не употребляется оператор сопоставления, к примеру -eq. Причина в том, что командлет Test-Path по определению возвращает True либо False, потому для обычной работы выражения эти значения не надо ни с чем ассоциировать.

Выражение в скобках в этой конструкции вырождается до обычного значения True либо False. Конкретно это происходит, когда вы используете команду, которая всегда возвращает True либо False, к примеру Test-Path. Как обычно, есть соответственная about-статья, где можно отыскать другие примеры использования этой конструкции.

Конструкция ForEach

Работа этой конструкции похожа на поведение командлета ForEach-Object. Различия исключительно в синтаксисе. Задачка ForEach — принять массив (либо набор, что в Windows PowerShell равносильно массиву) и выполнить его перечисление, чтоб можно было всякий раз работать с одним объектом:

$services = Get-Service
ForEach ($service in $services) {
$service.Stop()
}

Новенькие могут совсем не сложно запутаться с этой конструкцией. Помните, что множественное число слова «services» в британском для Windows PowerShell ничего не означает. Переменная именуется конкретно так, чтоб припоминать, что содержит одни либо несколько служб. Если это множественное число, то это не означает, что оболочка будет как-то особо его обрабатывать.

Ключевое слово «in» во 2-ой строке является частью синтаксиса ForEach. Имя $service — это просто случайное имя переменной. С таким же фуррором в этом месте могло быть им $fred либо $coffee.

Windows PowerShell будет повторно делать команды в фигурных скобках по отношению к каждому следующему объекту во 2-ой переменной ($services). Всякий раз оболочка будет принимать один объект из 2-ой переменной ($services) и помещать его в первую переменную ($service).

В конструкции первую переменную ($service) необходимо использовать как содержащую единичный объект. В третьей строке точка значит, что нужен не весь объект, а только один из его членов — способ Stop.

Время от времени случается так, что внедрение ForEach лучше и даже безизбежно. Но если у вас уже есть опыт программирования, вы сможете прибегать к ForEach, когда этого лучше не делать. В прошлом примере лучше не использовать ForEach. Разве не проще сделать так:

Get-Service | Stop-Service

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

Когда необходимо выполнить способ по отношению к набору объектов и нет командлета, который бы мог выполнить эту задачку.
Если есть набор объектов и по отношению к каждому необходимо выполнить ряд поочередных операций.
Когда операцию необходимо делать только по отношению к одному объекту за один раз, но в процессе выполнения сценария количество объектов — один либо несколько — заблаговременно непонятно.

Другие конструкции

В Windows PowerShell есть ряд других конструкций, в том числе Switch, For и другие. Они описаны в about-статьях оболочки. Время от времени их можно подменять уже описанными конструкциями. К примеру, можно поменять Switch конструкцией If с несколькими разделами ElseIf. For можно поменять ForEach либо даже командлетом ForEach-Object. Вот вам наглядный пример цикла, который производится ровно 10 раз:

1..10 | ForEach-Object -process {
# code here will repeat 10 times
# use $_ to access the current iteration
# number
}

Вы сами должны решать, какая конструкция лучше подойдет в той либо другой ситуации. Если будете находить сценарии в Вебе, будьте готовы к хоть каким вариантам.

Функции

Функция — это особенный вид конструкции, служащий для объединения группы взаимосвязанных команд для выполнения одной верно определенной задачки. Вообщем говоря, можно взять хоть какой сценарий Windows PowerShell и «обернуть» его в функцию:

function Mine {
Get-Service
Get-Process
}
Mine

Тут определена новенькая функция по имени Mine. Это, в сути, превращает Mine в команду, потому что запустить функцию можно, просто указав ее имя. Конкретно это и происходит в пятой строке.

Функции обычно располагают в файлах сценариев. Один сценарий может содержать несколько функций. А функции могут содержать внутри себя другие функции.

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

function One {
function Two {
Dir
}
Two
}
One
Two

Представьте, что вы расположили этот текст в файле сценария и выполнили его. В седьмой строке производится функция One, определение которой начинается на первой строке. В пятой строке производится функция Two, определение которой начинается на пятой строке. Потому в итоге получим перечень содержимого каталога — соответственная команда расположена на третьей строке в функции Two.

Но последующая выполняемая строчка (номер восемь) приведет к ошибке. В сценарии нет функции по имени Two. Функция Two спрятана в функции One. Потому функция Two существует исключительно в области деяния функции One и видна только из последней. Попытка вызвать Two из хоть какого другого места приведет к ошибке.

Характеристики в сценарии

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

Характеристики определяются особенным образом сначала сценария. Можно предварить это определение комментарием, но в любом случае это должна быть 1-ая исполняемая строчка сценария. В области определения характеристик любой из их отделяется запятой. Для удобства чтения каждый параметр рекомендуется располагать в своей строке. Вот вам наглядный пример:

param (
[string]$computername,
[string]$logfile,
[int]$attemptcount = 5
)

Тут определяются три параметра. В сценарии они употребляются как любые другие переменные. Вы наверное увидели, что в пятой строке я присвоил параметру $attemptcount значение по дефлоту. Это значение будет заменено значением входного параметра, но если он не будет задан, сценарий будет производиться со значением по дефлоту.

Вот несколько методов пуска сценария (подразумевается, что сценарий содержится в файле Test.ps1):

./test -computername SERVER
./test -comp SERVER -log err.txt -attempt 2
./test SERVER err.txt 2
./test SERVER 2
./test -log err.txt -attempt 2 -comp SERVER

Сценарий воспринимает характеристики фактически так же, как хоть какой командлет. В качестве имен характеристик употребляются имена переменных, а перед ними добавляется обычный для Windows PowerShell дефис. Вот описание того, как работают примеры.

В первой строке я задал только один из характеристик, потому $logfile будет пустым, а $attemptcount будет содержать 5, значение по дефлоту.
Во 2-ой строке я задал все три параметра, но при всем этом использовал сокращенные имена. Как и в командлетах, довольно задать только начало имени параметра, которого довольно для того, чтоб оболочка Windows PowerShell «поняла», о чем речь идет.
В третьей строке опять заданы все три параметра, но сейчас они заданы по позициям, без использования имен характеристик. Как я помню, если характеристики задавать точно в том порядке, в каком они определены в сценарии, все работает нормально.
В четвертой строке показано, что происходит, если не соблюдать осторожность. Тут $computername получит значение «SERVER», $logfile будет содержать 2, а $attemptcount — 5. Это не совершенно то, что мне было необходимо. Если не использовать имена характеристик, пропадает упругость. Также сторонним людям становится труднее осознать, что вы имели в виду, а это в свою очередь усложняет устранение вероятных проблем.
В пятой строке приведен наилучший пример. Тут я указал характеристики не в том порядке, в каком они определены, но это не жутко, так как я указал их имена. В общем случае рекомендуется использовать имена характеристик — это дает дополнительную упругость. Вам не надо будет держать в голове порядок, в каком они определены.

Более сложные сценарии

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

При всем этом механизм использования характеристик в сценарии не изменяется. Просто оболочке предоставляется чуток больше инфы о параметрах. Этот прием в большинстве случаев употребляется в функциях, но в сценариях этот синтаксис также допустим. Вот обычной пример:

[CmdletBinding()]
param (
[Parameter(Mandatory=$True)]
[string]$computername,
[Parameter(Mandatory=$True)]
[string]$logfile,
[int]$attemptcount = 5
)

Я добавил всего только аннотацию [CmdletBinding()] в первой исполняемой строке кода в сценарии. Перед этой строчкой не разрешается ничего располагать не считая комментариев. Я также присоединил к своим двум характеристикам аннотацию [Parameter()], где указал, что они неотклонимы. Сейчас если кто-то попробует выполнить сценарий, не задав эти характеристики, Windows PowerShell предложит ввести эту информацию.

Направьте внимание, что у последнего параметра нет никаких дополнительных инструкций, а все три параметра представляют собой разбитый запятыми перечень (другими словами после первых 2-ух характеристик стоят запятые). ). Есть масса другой инфы, которую можно задать для параметра и которая доступна в статье.

Это было очень резвое введение по теме сотворения сценариев в Windows PowerShell. Я надеюсь, что из этой статьи вы почерпнули что-то полезное. Создание параметризованных сценариев — в особенности нужная функциональность, так как позволяет создавать сценарии, которые смотрятся и ведут себя так же, как и истинные командлеты Windows PowerShell.

Аналогичный товар: Комментирование на данный момент запрещено, но Вы можете оставить ссылку на Ваш сайт.

Комментарии закрыты.