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 папки \Windows\System32\WindowsPowerShell.

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

Get-Service
Get-Process

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

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

Get-Service;Get-Process

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

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

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

Переменные

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

При использовании имени переменной ссылаются на сам «ящик». Если нужно сослаться на содержимое ящика, используйте знак доллара, например, так: $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 не говорит оболочке, что переменная будет содержать более одного числа. Оболочке также все равно, какое число вы используете, — единственное или множественное. Для оболочки следующее выражение:

$numbers = 1

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

$numbers = 'fred.'

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

Кавычки

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

Во-первых, это делают, когда нужно вставить содержимое переменной в строку. Только при наличии двойных кавычек 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"

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

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

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

$service = 'bits'
$name = "Service is $service.ToUpper()"
$upper = $name.ToUpper()
$name = "Service is $upper"

На второй строке $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] позволяет получить первый элемент массива, которым будет первая служба. Так как за этим следует точка, мы знаем, что идет обращение к свойству или методу этой службы, а не ко всему объекту. Наконец мы извлекаем только имя службы.

Во второй строке выражение в скобках читает содержимое текстового файла. Если файл содержит имена компьютеров — по одному в строке, 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. Именно эта команда выполнялась во втором случае. Все это никак не повлияло на псевдоним Dir верхнего уровня. Попытайтесь выполнить Dir в оболочке после запуска предыдущего сценария и вы снова получите список содержимого каталога.

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

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

Windows PowerShell содержит очень упрощенный язык сценариев, который состоит менее чем из двух дюжин слов. Он сильно отличается от полноценного языка программирования, такого как 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, который выполняется, если не выполнился ни один из предыдущих блоков команд.  Выполнится только первый блок команд, для которого выражение в скобках равно True. Например, если $this не равно $that, а $those не равно $them, тогда будут выполнены только команды в четвертой строке. Windows PowerShell даже не станет вычислять выражение для elseif в пятой строке.

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

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

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

В среде 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 вычисляется не ранее, чем первый раз выполнится блок команд. Можно перенести While — тогда команды будут выполнены, только если с самого начала условие равно True:

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

Заметьте, что во втором примере не используется оператор сравнения, например -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» во второй строке является частью синтаксиса ForEach. Имя $service — это просто произвольное имя переменной. С таким же успехом в этом месте могло быть им $fred или $coffee.

Windows PowerShell будет повторно выполнять команды в фигурных скобках по отношению к каждому очередному объекту во второй переменной ($services). Каждый раз оболочка будет принимать один объект из второй переменной ($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. Вот пример цикла, который выполняется ровно десять раз:

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 из любого другого места приведет к ошибке.

Параметры в сценарии

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

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

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

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

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