Powershell параметры командной строки

Что такое Windows PowerShell и с чем его едят? Часть 3: передача параметров в скрипты и функции, создание командлетов

Powershell параметры командной строки

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

Позиционные параметры
Блок Param()
Дополнительные атрибуты параметров
Передача параметров через конвейер
Структура тела функции
Атрибут [CmdletBinding()] и расширенные функции
Модули сценариев и создание командлетов
В сценарии и функции можно передавать позиционные параметры (аргументы), значения которых записываются во встроенную переменную $args. Этот одномерный массив не требует предварительного объявления, а область его видимости ограничивается скриптом или функцией. Для примера запустим простейший сценарий: Write-Host “Передано аргументов:” $args.countWrite-Host “Аргументы:” $args В функциях позиционные параметры используются аналогично: function Print-Args { Write-Host “Передано аргументов:” $args.count Write-Host “Аргумент 0:” $args[0] Write-Host “Аргумент 1:” $args[1] } Print-Args «Ноль» «Один» Обратите внимание, что при вызове Print-Args мы не ставим запятую между параметрами: в функцию передается не массив, а отдельные значения, которые записываются в одномерный массив $args — его область видимости ограничена телом функции. Описанный выше способ позволяет передать в сценарий или функцию любое количество параметров, но при вызове необходимо соблюдать порядок их следования, а обращаться к ним можно только по индексу массива — это не всегда удобно.
В сценариях и функциях намного удобнее использовать именованные параметры. В предыдущей статье мы рассказывали об одном способе их описания: function test ($arg0, …, $argN){ }
Подобный синтаксис привычен разработчикам, но при вызове функции параметры (если они есть) разделяются пробелами, а не заключаются в круглые скобки — возникает некоторый диссонанс. Такова специфика shell-языков: для работы с командным интерпретатором в интерактивном режиме пробелы между значениями намного удобнее. Вызов test($value0) также корректен, но параметром при этом является все выражение в скобках, т.е. ($value0) вместо $value0. Передать таким способом несколько параметров уже не выйдет. В результате вызова test($value0, $value1) функция получит только один — массив из двух элементов со значениями $value0 и $value1. Корпорация Microsoft рекомендует использовать блок Param() — этот синтаксис более универсален и позволяет задавать не только аргументы функций, но и параметры сценариев: param ( $arg0, $arg1) Write-Host $arg0 $arg1 В теле функции это выглядит так: function test { param ( $arg0, $arg1 )} Если список аргументов функции невелик, блок Param() только загромоздит конструкцию, но во многих случаях он делает код более читаемым и является помимо прочего элементом хорошего стиля программирования. При описании аргументов функции или параметров скрипта можно задать их дополнительные атрибуты. Самый простой пример — принудительная установка типа: param([int]$arg0) или function test ([int]$arg0) {} Помимо приведения типов можно использовать атрибут [parameter()]: param( [parameter(Argument1=value1, Argument2=value2)] $ParameterName) С его помощью нетрудно сделать параметр обязательным. Обратите внимание на одновременное использование нескольких атрибутов — в этом случае они идут друг за другом: param([parameter(Mandatory=$true)][int]$arg0) или function test ([parameter(Mandatory=$true)][int]$arg0) { } или function test { parameter([parameter(Mandatory=$true)][int]$arg0)} Position позволяет указать порядок следования параметра (по умолчанию он соответствует порядку объявления): param( [parameter(Mandatory=$true, Position=0)] [int] $arg0, [parameter(Position=1)] [string] $arg1, [parameter(Position=2)] [array] $arg2)
У атрибута [Parameter()] есть и другие аргументы, полный список которых доступен на сайте Microsoft. Там же описаны прочие атрибуты, с помощью которых можно провести валидацию переданных значений, проверить их с использованием регулярных выражений и т.д. Перечислим некоторые:

[Alias()] устанавливает псевдоним для параметра:

param( [parameter(Mandatory=$true)] [alias(“ARG”,”ArgumentName”)] [string[]] $arg0) Оператор приведения типов [string[]] означает, что значение параметра — строковый массив.

[AllowNull()] разрешает $null в качестве обязательного параметра:

param( [parameter(Mandatory=$true)] [AllowNull()] [string] $arg0)
[AllowEmptyString()] разрешает пустую строку в качестве обязательного параметра: param( [parameter(Mandatory=$true)] [AllowEmptyString()] [string] $arg0)
[AllowEmptyCollection()] разрешает пустой массив в качестве обязательного параметра: param( [parameter(Mandatory=$true)] [AllowEmptyCollection()] [string[]] $arg0)
[ValidatePattern()] проверка с использованием регулярного выражения: param( [parameter(Mandatory=$true)] [ValidatePattern(“[0-9][0-9][0-9][0-9]”)] [string[]] $arg0)
[ValidateLength()] проверяет длину строкового параметра: param( [parameter(Mandatory=$true)] [ValidateLength(1,10)] [string] $arg0)

В первой статье цикла мы рассказывали о возможности передачи данных в командлеты через конвейер (pipeline). В PowerShell командлеты и функции возвращают объекты или массивы объектов (результаты стейтментов), а также получают их на входе. Чтобы это увидеть, препарируем один из командлетов при помощи Get-Help: Get-Help Stop-Process -Parameter Name Через конвейер можно принять значения параметров, для которых установлены соответствующие атрибуты (ByValue и/или ByPropertyName). В первом случае параметру будет сопоставлен поступивший по конвейеру объект при условии, что его тип соответствует ожидаемому. Во втором значением параметра будет свойство входящего объекта, имя которого соответствует имени или псевдониму этого параметра. Для установки атрибутов используется [parameter()] с булевыми аргументами ValueFromPipeline и ValueFromPipelineByPropertyName, значение которых по умолчанию равно $false: param( [parameter(Mandatory=$true, ValueFromPipeline=$true)] [string[]] $Name) или param( [parameter(Mandatory=$true, ValueFromPipelineByPropertyName=$true)] [string[]] $Name) ValueFromPipelineByPropertyName обычно используют при необходимости передать несколько параметров, чтобы не возникало путаницы, при этом аргумент можно применять одновременно с ValueFromPipeline: param( [parameter(Mandatory=$true, ValueFromPipeline=$true, ValueFromPipelineByPropertyName=$true)] [string[]] $Name) Write-Host $Name

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

В языке PowerShell функция может включать три необязательных блока заключенного в операторные скобки кода — Begin, Process и End. Выглядит она примерно так: function test{ param() begin {} process {} end {}} Первым однократно выполняется блок Begin, причем если параметры передаются в функцию через конвейер, код запустится еще до поступления первого объекта на обработку. Переменные $_ и $PSItem в блоке Begin в этом случае не будут содержать значений. Если же функция вызывается с использованием явным образом заданных параметров, они будут доступны и в блоке Begin, поскольку нет необходимости ожидать получения объектов из конвейера. Далее выполняется блок Process: если параметры передаются через конвейер, он будет поочередно запущен для каждого объекта. В случае явным образом заданных параметров блок Process запустится только один раз. Завершается работа функции однократным выполнением блока End. Очевидно, что использование этих конструкций оправдано, только если функция может принимать объекты из конвейера: function test{ param( [Parameter(ValueFromPipeline)] [string[]] $Param1, [string]$Param2 ) begin { Write-Host “Блок Begin” Write-Host ” Первый параметр (через pipeline):” $Param1 Write-Host ” Второй параметр (аргумент функции):” $Param2 } process { Write-Host “Блок Process” Write-Host ” Первый параметр (через pipeline):” $Param1 Write-Host ” Второй параметр (аргумент функции):” $Param2 } end { Write-Host “Блок End” Write-Host ” Первый параметр (через pipeline):” $Param1 Write-Host ” Второй параметр (аргумент функции):” $Param2 }} 'один', 'два', 'три' | test -Param2 'четыре'
Для создания «продвинутых» функций (и скриптов строго говоря) можно использовать атрибут [CmdletBinding()]. Он, в частности, позволяет определять расширенные функции с возможностями скомпилированных в Visual Studio бинарных командлетов, представляющих собой классы классы .NET Core. Поскольку применяется этот атрибут в основном в функциях, на них мы и остановимся: function { [CmdletBinding(ConfirmImpact=, DefaultParameterSetName=, HelpURI=, SupportsPaging=, SupportsShouldProcess=, PositionalBinding=)] Param () Begin{} Process{} End{}}
На самом деле [CmdletBinding()] инициализирует новый экземпляр класса CmdletBindingAttribute через вызов конструктора, которому можно передать необязательные аргументы. Их подробное описание есть на сайте Microsoft. Атрибут CmdletBinding позволяет контролировать дополнительные возможности расширенной функции: добавление поддержки -Confirm и -WhatIf (через SupportsShouldProcess), -Force, -Verbose и -Debug, а также отключение позиционного связывания параметров и т.д. Дальше мы разберем использование специальных параметров.

Параметр -Force применяется для подавления запросов на проведение различных операций;

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

Remove-Item C:\Windowsotepad.exe -WhatIf

-Confirm требует подтверждения и также используется, если функция может выполнить деструктивные действия.

function Delete-File {[CmdletBinding( ConfirmImpact = 'High', SupportsShouldProcess = $true)] param( [string]$File, [switch]$Force ) if ($Force -or $PSCmdlet.ShouldProcess($File,”Delete file”)) { Remove-Item $File }} Для обработки -WhatIf и/или -Confirm вызывается метод ShouldProcess (SupportsShouldProcess=$true), который выводит запрос или эмулирует выполнение команды. Чтобы реализовать обработку -Force, мы поместили его первым в условие IF. Сначала проверяется выражение слева от оператора -or и если оно истинно, проверка останавливается — метод ShouldProcess вызываться не будет. Также в атрибуте [CmdletBinding()] мы указали аргумент ConfirmImpact, определяющий уровень воздействия кода на систему и включающий обработчик параметра -Confirm. Этот аргумент может принимать следующие значения:

None или не указан — сообщения о подтверждении выводиться не будут, даже если передан параметр -Confirm.

Low — функция незначительно воздействует на систему и не создает существенных рисков потери данных.

Medium — среднее воздействие с незначительным риском потери данных в результате деструктивных действий.

High — код создает высокий риск потери данных в результате деструктивных действий.

По умолчанию для сессии PowerShell уровень воздействия считается высоким (High). Актуальное значение хранится в переменной $ConfirmPreference и если у кода уровень воздействия на систему такой же или более высокий, запрос на подтверждение будет выводиться всегда.

Параметры -Verbose и -Debug нужны для вывода отладочной информации. Их использование считается хорошим стилем программирования (забудьте про Write-Host, в расширенных функциях это не нужно).

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

Поведение -Verbose и -Debug определяется примерно так:

function Get-Something {[CmdletBinding()] param() if ($PSBoundParameters.Verbose) {$VerbosePreference = “Continue”} if ($PSBoundParameters.Debug) {$DebugPreference = “Continue”} Write-Verbose “Type some verbose information” Write-Debug “Type some debug information”} Для работы со специальными параметрами мы использовали переменную $PSBoundParameters. По умолчанию значения $VerbosePreference и $DebugPreference равны 'SilentlyContinue', поэтому даже при указании соответствующих параметров отладочная информация выводиться не будет — их нужно перевести в состояние 'Continue'.
Приступим к созданию собственных командлетов. По сути это расширенные функции, которые описаны в т.н. модулях сценариев — текстовых файлах с расширением .psm1. Хранятся они в каталогах, определенных в переменной окружения PSModulePath. Посмотреть пути к ним можно при помощи следующей команды: Get-ChildItem Env:\PSModulePath | Format-Table -AutoSize Стандартный набор выглядит примерно так: C:\Users\%UserName%\Documents\WindowsPowerShell\Modules C:\Program Files\WindowsPowerShell\Modules C:\Windows\System32\WindowsPowerShell\v1.0\Modules

После создания файла ModuleName.psm1 с расширенной функцией Delete-File из предыдущего раздела, его нужно сохранить, например, в ]C:\Users\%UserName%\Documents\WindowsPowerShell\Modules\ModuleName.

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

После запуска команды Import-Module ModuleName функция Delete-File станет доступна пользователю, а поскольку она расширенная, с практической точки зрения это тот же командлет.

В этой статье мы достаточно подробно разобрали передачу параметров в функции и скрипты. Следующая часть цикла будет посвящена объектно-ориентированному программированию.

Часть 1: основные возможности Windows PowerShell

Часть 2: введение в язык программирования Windows PowerShell
Часть 4: Работа с объектами, собственные классы

Источник: https://habr.com/ru/company/ruvds/blog/493366/

Передача аргументов командной строки в среду PowerShell

Powershell параметры командной строки

26.05.2014 Ален Вайт

Вы можете задействовать сценарии для автоматизации всех процессов управления системой SQL Server, поскольку это позволяет убедиться, что задачи выполняются стабильно и с приложением минимальных усилий. И в самом деле, ведь не хотите же вы использовать графический интерфейс среды SQL Server Management Studio, SSMS, для резервного копирования содержимого всех баз данных своей сети — или я ошибаюсь?

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

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

В большинстве сценариев, с которыми мне приходится иметь дело, я передаю имя сервера (точнее сказать, экземпляра SQL Server, но поскольку при работе с интерфейсом SQL Server Management Objects (SMO) полагается оперировать объектом Server, я использую термин «server» для обозначения этого экземпляра). Блок param я размещаю на месте первого исполняемого модуля, который PowerShell видит в моем сценарии, и поэтому оболочка воспринимает переменные, определяемые мною, как аргументы командной строки, так что в моих сценариях я определяю сервер, к которому необходимо подключиться, следующим образом:

param {[string] $inst = $null}

Итак, если мой сценарий называется Get-DatabaseOptions.ps1, я запущу его для работы с сервером WS12SQL01, используя при этом следующий вызов из командной строки:

PS C:\Demos>./Get-DatabaseOptions.ps1 WS12SQL01

Таким образом, в начале выполнения сценария переменной $inst будет присвоено значение 'WS12SQL01', и это значение будет использоваться с целью подключения к данному серверу для его обработки.

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

А что произойдет, если вы передадите программе второй аргумент? Ответ — по умолчанию PowerShell возвратит дополнительные аргументы в коллекции $args, и вы при желании сможете использовать их в своем сценарии.

PS C:\Demos>. \Get-DatabaseOptions.ps1 WS12SQL01 AdventureWorks$inst = WS12SQL01$args = AdventureWorks

Поскольку согласно моему замыслу сценарий должен был принимать только один аргумент, я решил использовать директиву CmdletBinding(), которая сообщает оболочке PowerShell, что допускается применение только заданных аргументов (наряду с прочими объектами, описание которых выходит за рамки данной статьи).

CmdletBinding()]param ([string] $inst = $null)

А если я попытаюсь включить параметр AdventureWorks, PowerShell выдаст сообщение об ошибке, как на рисунке 1.

Рисунок 1. Сообщение об ошибке

Непосредственно перед определением переменной $inst я могу добавить следующую строку, в которой будет содержаться запрос на ввод аргумента:

[Parameter(Mandatory=$true)]

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

cmdlet Get-DatabaseOptions.ps1 at command pipeline position 1

Supply values for the following parameters:

inst:

Сценарий дает пользователю возможность ввести параметр и затем продолжает выполняться с использованием предложенного значения.

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

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

Get-Service | Stop-Service

мы можем получить нежелательные результаты, но если мы дополним эту команду аргументом -WhatIf, то сможем увидеть, каковы будут эти результаты, причем далее PowerShell подготовит отчет о каждой службе и сообщит нам, что действие этой службы приостанавливается, см. рисунок 2.

Рисунок 2. Состояние служб

Еще одна возможность, реализованная в директиве CmdletBinding(), позволяет пользователю включить ту же возможность в свой сценарий. Чтобы активировать эту функцию, введите в скобки директивы CmdletBinding() параметр SupportsShouldProcess=$True.

Встроенная переменная $PSCmdlet содержит сведения о стеке вызовов и наделена свойством ShouldProcess, значение которого можно проверить. Если данному свойству назначено значение $False, в дело вступает аргумент -WhatIf, и вы можете не допустить фактического выполнения определенных в сценарии действий.

Поскольку код, в котором условия имеют значение $True, представляется более ясным, наш код будет выглядеть следующим образом:

[CmdletBinding(SupportsShouldProcess=$True)]param ([Parameter(Mandatory=$true)][string] $inst = $null)if ($PSCmdlet.ShouldProcess(«$inst»,«Return Database Options»)){write-output «Do stuff on server `$inst = $inst»}

Если мы включим в команду аргумент -Whatif, PowerShell возвратит следующие данные.

What if: Performing operation «Return Database Options» on Target «WS12SQL01».

Если аргумент -Whatif не используется, мы получаем обычные результаты обработки.

PS C:\Demos>. \Get-DatabaseOptions.ps1 WS12SQL01 Do stuff on server $inst = WS12SQL01

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

PowerShell обеспечивает возможность выполнения процессов инициализации, итеративных процессов и процессов упаковки с помощью блоков Begin {}, Process {} и End {}.

Блок Begin {} выполняется однократно, блок Process {} выполняется по одному разу для каждого переданного по конвейеру значения, а блок End {} — однократно в ситуации, когда конвейер пуст.

Пользователю нет нужды производить какие-либо операции в начале или в конце конвейера, но вы можете с помощью блока Process {} активировать упомянутую функцию и, получив набор серверов из конвейера, выполнить свой сценарий применительно к каждому из них.

Прежде всего, вам следует дополнить блок param еще одним компонентом — аргументом ValueFromPipeline. Дополнение вносится непосредственно в раздел определения Parameter.

param ([Parameter(Mandatory=$true,ValueFromPipeline=$true)][string] $inst = $null)

Теперь введите логику в блок сценария Process {} — и можете приступать к работе.

Process {if ($PSCmdlet.ShouldProcess(«$inst»,«Return Database Options»)) {foreach ($svr in $inst){write-output «Do stuff on server `$inst = $inst»}}}

Вы можете запускать сценарий так же, как и раньше.

PS C:\Demos>. \Get-DatabaseOptions.ps1 WS12SQL01Do stuff on server $inst = WS12SQL01

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

Рисунок 3. Обработка нескольких серверов

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

Передача аргументов командной строки в среду PowerShell

Поделитесь материалом с коллегами и друзьями

Источник: https://www.osp.ru/winitpro/2014/06/13041409

Наборы параметров командлета – PowerShell

Powershell параметры командной строки

  • 09/13/2016
  • Чтение занимает 2 мин
    • j
    • o

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

PowerShell uses parameter sets to enable you to write a single cmdlet that can do different actions for different scenarios. Наборы параметров позволяют предоставлять пользователю различные параметры.Parameter sets enable you to expose different parameters to the user.

И, чтобы получить различные сведения на основе параметров, указанных пользователем.And, to return different information the parameters specified by the user.

Примеры наборов параметровExamples of parameter sets

Например, Get-EventLog командлет PowerShell возвращает различные сведения в зависимости от того, указывает ли пользователь параметр List или i .For example, the PowerShell Get-EventLog cmdlet returns different information depending on whether the user specifies the List or LogName parameter.

Если указан параметр List , командлет возвращает сведения о самих файлах журнала, но не сведения о событиях, которые они содержат.If the List parameter is specified, the cmdlet returns information about the log files themselves but not the event information they contain.

Если указан параметр ” /l “, командлет возвращает сведения о событиях в определенном журнале событий.If the LogName parameter is specified, the cmdlet returns information about the events in a specific event log. Параметры List и параметров задания указывают два отдельных набора параметров.

The List and LogName parameters identify two separate parameter sets.

Уникальный параметрUnique parameter

Каждый набор параметров должен иметь уникальный параметр, используемый средой выполнения PowerShell для предоставления соответствующего набора параметров.Each parameter set must have a unique parameter that the PowerShell runtime uses to expose the appropriate parameter set.

Если это возможно, уникальный параметр должен быть обязательным.If possible, the unique parameter should be a mandatory parameter. Если параметр является обязательным, пользователь должен указать параметр, а среда выполнения PowerShell использует этот параметр для определения набора параметров.

When a parameter is mandatory, the user must specify the parameter, and the PowerShell runtime uses that parameter to identify the parameter set. Уникальный параметр не может быть обязательным, если командлет предназначен для запуска без указания каких-либо параметров.

The unique parameter can't be mandatory if your cmdlet is designed to run without specifying any parameters.

Несколько наборов параметровMultiple parameter sets

На следующем рисунке в левом столбце показаны три допустимых набора параметров.In the following illustration, the left column shows three valid parameter sets.

Параметр A уникален для первого набора параметров, параметр B уникален для второго набора параметров, а параметр C является уникальным для третьего набора параметров.

Parameter A is unique to the first parameter set, parameter B is unique to the second parameter set, and parameter C is unique to the third parameter set. В правом столбце наборы параметров не имеют уникального параметра.In the right column, the parameter sets don't have a unique parameter.

Требования к наборам параметровParameter set requirements

Следующие требования применяются ко всем наборам параметров.The following requirements apply to all parameter sets.

  • Каждый набор параметров должен иметь по крайней мере один уникальный параметр.Each parameter set must have at least one unique parameter. Если это возможно, присвоить этому параметру обязательный параметр.If possible, make this parameter a mandatory parameter.

  • Набор параметров, содержащий несколько позиционированных параметров, должен определять уникальные позиции для каждого параметра.A parameter set that contains multiple positional parameters must define unique positions for each parameter. Ни один из двух параметров позиционирования не может указывать одну и ту же точку.No two positional parameters can specify the same position.

  • Только один параметр в наборе может объявить ValueFromPipeline ключевое слово со значением true .Only one parameter in a set can declare the ValueFromPipeline keyword with a value of true.Несколько параметров могут определять ValueFromPipelineByPropertyName ключевое слово со значением true .Multiple parameters can define the ValueFromPipelineByPropertyName keyword with a value of true.

  • Если для параметра не задан набор параметров, параметр относится ко всем наборам параметров.If no parameter set is specified for a parameter, the parameter belongs to all parameter sets.

Примечание

Для командлета или функции существует ограничение в 32 наборов параметров.For a cmdlet or function, there is a limit of 32 parameter sets.

Наборы параметров по умолчаниюDefault parameter sets

Если определено несколько наборов параметров, можно использовать DefaultParameterSetName ключевое слово атрибута командлета для указания набора параметров по умолчанию.

When multiple parameter sets are defined, you can use the DefaultParameterSetName keyword of the Cmdlet attribute to specify the default parameter set.

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

PowerShell uses the default parameter set if it can't determine the parameter set to use the information provided by the command. Дополнительные сведения об атрибуте командлета см. в разделе объявление атрибута командлета.For more information about the Cmdlet attribute, see Cmdlet Attribute Declaration.

Объявление наборов параметровDeclaring parameter sets

Чтобы создать набор параметров, необходимо указать ParameterSetName ключевое слово при объявлении атрибута Parameter для каждого параметра в наборе параметров.

To create a parameter set, you must specify the ParameterSetName keyword when you declare the Parameter attribute for every parameter in the parameter set.

Для параметров, принадлежащих к нескольким наборам параметров, добавьте атрибут параметра для каждого набора параметров.For parameters that belong to multiple parameter sets, add a Parameter attribute for each parameter set.

Этот атрибут позволяет определить параметр по-разному для каждого набора параметров.This attribute enables you to define the parameter differently for each parameter set. Например, можно определить параметр как обязательный в одном наборе и необязательный в другом.

For example, you can define a parameter as mandatory in one set and optional in another. Однако каждый набор параметров должен содержать один уникальный параметр.However, each parameter set must contain one unique parameter. Дополнительные сведения см. в разделе объявление атрибута Parameter.For more information, see Parameter Attribute Declaration.

В следующем примере параметр username является уникальным параметром Test01 набора параметров, а параметр ComputerName — уникальным параметром Test02 набора параметров.

In the following example, the UserName parameter is the unique parameter of the Test01 parameter set, and the ComputerName parameter is the unique parameter of the Test02 parameter set.

Параметр шаредпарам относится к обоим наборам и является обязательным для Test01 набора параметров, но необязателен для Test02 набора параметров.The SharedParam parameter belongs to both sets and is mandatory for the Test01 parameter set but optional for the Test02 parameter set.
[Parameter(Position = 0, Mandatory = true, ParameterSetName = “Test01”)]public string UserName{ get { return userName; } set { userName = value; }}private string userName; [Parameter(Position = 0, Mandatory = true, ParameterSetName = “Test02”)]public string ComputerName{ get { return computerName; } set { computerName = value; }}private string computerName; [Parameter(Mandatory= true, ParameterSetName = “Test01”)][Parameter(ParameterSetName = “Test02”)]public string SharedParam{ get { return sharedParam; } set { sharedParam = value; }}private string sharedParam;

Источник: https://docs.microsoft.com/ru-ru/powershell/scripting/developer/cmdlet/cmdlet-parameter-sets?view=powershell-7

Поделиться:
Нет комментариев

    Добавить комментарий

    Ваш e-mail не будет опубликован. Все поля обязательны для заполнения.