Powershell параметры: Параметры командлета — PowerShell | Microsoft Learn

Параметры командлета — PowerShell | Microsoft Learn

Twitter




LinkedIn




Facebook




Адрес электронной почты

• 
  Статья
• 
  09/27/2021
• 
  

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

в этом разделе

Объявление свойств как параметров Предоставляет основные сведения, которые необходимо понимать перед объявлением параметров командлета.

Типы параметров командлета Описывает различные типы параметров, которые можно объявить в командлетах.

Имя параметра командлета и рекомендации по функциональности Описывает имена, Рекомендуемые типы данных и функциональные возможности стандартных параметров.

Псевдонимы параметров Описывает псевдонимы, которые можно определить для параметров.

Общие имена параметров в этом разделе описываются параметры, которые Windows PowerShell добавляются в командлеты.

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

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

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

Проверка входных параметров описывает, как Windows PowerShell проверяет аргументы, передаваемые в параметры командлета.

Параметры входного фильтра Описывает Filter Include Параметры, и Exclude , которые фильтруют набор входных объектов, на которые влияет командлет.

Как проверить входные параметры

См. также:

Объявление атрибута параметра

Командлеты Windows PowerShell

Обратная связь

Просмотреть все отзывы по странице

Передача параметров в PowerShell

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

Самый простой вариант передачи данных — использовать встроенную переменную $args, которая имеет тип одномерный массив (hashtable). Для этого создадим скрипт с именем service.ps1 вот такого содержания:

Get-Service -Name $args[0] -ComputerName $args[1]

Этот скрипт должен вывести состояние заданного сервиса\сервисов для одного или нескольких компьютеров. Имя сервиса и компьютера передаются в скрипт в качестве аргументов.

Теперь выполним его, указав в качестве аргументов сервис печати (spooler) и имя компьютера SRV1:

.\service.ps1 spooler SRV1

Получив эту команду, PowerShell подставит вместо $args[0] название сервиса, вместо $args[1] имя компьютера и выведет полученный результат.

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

Более эффективным способом передачи параметров является использование в сценарии блока param. Для примера возьмем наш сценарий и изменим его:

Param (
[string]$service,
[string]$computer
)

Get-Service -ServiceName $service -ComputerName $computer

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

.\service.ps1 -Service spooler -Computer SRV1

Чтобы вводить меньше текста, имена параметров можно сократить, например так:

.\service.ps1 -Serv spooler -Comp SRV1

Имена можно и совсем опустить, хотя это и не очень правильно. В этом случае PowerShell примет значения параметров в том порядке, в каком они указаны в команде. Так же как и при использовании $args, значения надо указывать в том же порядке, в котором они перечислены в сценарии:

.\service.ps1 spooler SRV1

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

[CmdletBinding()]

Param (
[Parameter (Mandatory=$true, Position=1)]
[string]$service,

[Parameter (Mandatory=$true, Position=2)]
[string]$computer
)

Get-Service -ServiceName $service -ComputerName $computer

Здесь оба параметра указаны как обязательные (Mandatory=$true) и для каждого задана своя позиция. Это значит, что оба параметра обязательно должны быть указаны и должны идти строго в определенном порядке. Теперь если не указать один из параметров, то PowerShell автоматически напомнит об этом и предложит ввести недостающую информацию.

Использование расширенного синтаксиса позволяет задавать различные ограничения для вводимых параметров. Еще раз изменим сценарий, указав в нем для имени компьютера ограничение в 3 символа (ValidateLength(1,3):

CmdletBinding()]

Param (
[Parameter (Mandatory=$true)]
[string]$service,

[Parameter (Mandatory=$true)]
[ValidateLength(1,3)]
[string]$computer
)

Get-Service -ServiceName $service -ComputerName $computer

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

.\service.ps1 -Service spooler -Computer SRV1.contoso.com

А такая отработает нормально:

.\service.ps1 -Service spooler -Computer SRV1

Подобным образом можно задавать практически любые ограничения для входных параметров. Для этого есть возможность использовать регулярные выражения, скрипты и пр. Узнать подробнее об этих возможностях можно, выполнив в PowerShell команду help about_functions_advanced_parameters.

404: Страница не найдена

ПоискWindowsServer

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

Что я могу сделать сейчас?

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

Поиск

• Узнайте последние новости.
• Наша домашняя страница содержит последнюю информацию о Windows Server.
• Наша страница «О нас» содержит дополнительную информацию о сайте, на котором вы находитесь, SearchWindowsServer.
• Если вам нужно, свяжитесь с нами, мы будем рады услышать от вас.

Просмотр по категории

Облачные вычисления

• 
  Как создавать моментальные снимки Amazon EBS и управлять ими через интерфейс командной строки AWS
  9Моментальные снимки 0002 EBS являются неотъемлемой частью любой стратегии резервного копирования и восстановления данных в развертываниях на основе EC2. Ознакомьтесь с тем, как …

• 
  Цены на облачную инфраструктуру взлетели на 30%

  Сложные макроэкономические условия, а также высокие средние цены реализации облачных вычислений и серверов хранения вынудили …

• 
  Разверните приложение с малой задержкой с помощью AWS Local Zones за 5 шагов

  Как только вы решите, что локальные зоны AWS подходят для вашего приложения, пришло время для развертывания. Следуйте этому пошаговому видео…

Корпоративный настольный компьютер

• 
  Роль шифрования файлов и папок Mac для бизнеса

  ИТ-администраторы могут включить утилиту Mac FileVault для бизнес-файлов и данных, чтобы обеспечить дополнительный уровень безопасности и …

• 
  Стоит ли использовать AppleCare+ для корпоративных организаций?

  AppleCare — полезная ограниченная гарантия, которая распространяется на все устройства Apple, но некоторым организациям следует учитывать преимущества . ..

• 
  Развертывание консоли диспетчера конфигурации Microsoft Intune

  Организации, желающие развернуть консоль Microsoft Configuration Manager, должны правильно настроить эту платформу и …

Виртуальный рабочий стол

• 
  Как избежать избыточного выделения ресурсов VDI

  ИТ-отдел должен распределять ресурсы VDI сбалансированным образом, чтобы предотвратить избыточное выделение ресурсов VDI. Узнайте о распространенных ошибках избыточного выделения ресурсов и…

• 
  Устранение проблем с производительностью VDI с помощью управления ресурсами

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

• 
  Пришло ли время для нового имени для тонких клиентов?

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

Как использовать параметры в PowerShell, часть I

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

Серии на данный момент:

1. Как использовать параметры в PowerShell, часть I
2. Как использовать параметры пользователя в PowerShell, часть II

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

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

Однако в то время я хотел сделать это лучше, и не только для этой переменной, но и для других, которые я использую в скрипте. Когда я писал этот сценарий, я только начинал писать PowerShell, поэтому я просто жестко запрограммировал в нем переменные. Вскоре стало очевидно, что это было далеко не оптимально, когда мне нужно было перенести сценарий из Dev\UAT в рабочую среду, поскольку некоторые переменные нужно было обновить между средами.

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

Давайте поспорим

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

Если вы запустите это из PowerShell ISE, нажав F5 , ничего интересного не произойдет. Это случай, когда вам нужно будет запустить сохраненный файл из консоли ISE и указать значение для аргумента.

Чтобы убедиться, что PowerShell выполняет то, что вы хотите, перейдите в командной строке в тот же каталог, где вы будете сохранять свои сценарии. Назовите сценарий Безымянные_Arguments_Example_1.ps1 и запустите его с аргументом FOO . Он вернет FOO . (Скрипты для этой статьи можно найти здесь.)

Вы, наверное, уже догадались, что, поскольку $args является массивом, вы можете получить доступ к нескольким значениям из командной строки.

Сохраните следующий скрипт как Безымянные_Arguments_Example_2.ps1.

Запустите его следующим образом:

Вы должны увидеть:

Одна из приятных возможностей чтения аргументов таким образом заключается в том, что вы можете передать произвольное количество аргументов, если вам это нужно. Сохраните следующий пример как Безымянные_Arguments_Example_3.ps1

Если вы назовете его следующим образом:

Вы должны получить:

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

Использование именованных параметров

Скопируйте следующий сценарий и сохраните его как Named_Parameters_Example_1.ps1 .

Затем запустите его.

При таком запуске ничего не произойдет.

Но теперь введите:

И вы увидите, как ваш сценарий возвращает слово test .

Это то, что вы могли бы ожидать, но скажем, у вас есть несколько параметров и вы хотите убедиться, что вы присвоили правильное значение каждому из них. У вас могут возникнуть проблемы с запоминанием их имен и, возможно, их порядка. Но это нормально; PowerShell умный. Введите ту же команду, что и выше, но добавьте тире (-) в конце.

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

Теперь, если вы нажмете Enter, вы снова увидите эхо слова test .

Если вы запускаете сценарий непосредственно из самой PowerShell, а не из ISE, завершение на вкладке по-прежнему будет отображать доступные параметры, но не будет отображать их на красивом маленьком дисплее.

Создайте и сохраните следующий скрипт как Named_Parameters_Example_2. ps1 .

Обратите внимание, что теперь у вас есть два параметра.

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

Результат будет:

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

Это приведет к тому же результату, что и выше, чего и следует ожидать:

параметров (таких как –envname выше), когда вы пытаетесь использовать завершение табуляции для другого параметра, отображаются только остальные параметры. Другими словами, PowerShell не позволит вам ввести один и тот же параметр дважды, если вы используете завершение с помощью табуляции.

Если вы дважды зададите одно и то же имя параметра, PowerShell выдаст вам ошибку, похожую на:

Один из вопросов, который, вероятно, приходит на ум в этот момент, заключается в том, как вы будете обрабатывать параметр с пробелом в нем. Например, как ввести путь к файлу вида C:\path to file\File.ext .

Ответ прост; можно заключить параметр в кавычки:

Результатом кода будет:

Благодаря гибкости PowerShell и цитированию вы можете сделать что-то вроде:

Вы увидите это сообщение обратно:

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

Это приводит к вводу ваших переменных параметров. Обычно я не делаю этого для переменных в самих скриптах PowerShell (поскольку в большинстве случаев я контролирую, как используются эти переменные), но я почти всегда гарантирую типизацию своих переменных параметров, чтобы иметь некоторую проверку ввода.

Подумайте, почему это может быть важно. Сохраните следующий сценарий как Named_Parameters_Example_3.ps1

Теперь запустите его следующим образом:

Вы получите ожидаемые результаты:

Что делать, если вы не контролируете передаваемые данные, а программа передачи передает элементы в строках в кавычках?

Для имитации запуска скрипта с небольшой модификацией:

Это приведет к:

Если вы вместо этого объявите $maybeanInt как [int] , как вы сделали $anInt , вы можете быть уверены, что они складываются вместе, а не объединяются.

Однако имейте в виду, если кто-то попытается вызвать тот же скрипт с реальной строкой, такой как:

Он вернет сообщение о грубой ошибке, так что это палка о двух концах.

Использование значений по умолчанию

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

Измените сценарий Named_Parameters_Example_2.ps1 следующим образом и сохраните его как Named_Parameters_Example_4.ps1

А затем запустите его следующим образом:

Не беспокойтесь о вводе имени среды. Вы должны получить:

Это не сильно экономит на наборе текста, но делает его немного проще и означает, что вам не нужно запоминать, как пишется Одиссея !

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

Сохраните следующий скрипт как Named_Parameters_Example_5.ps1 .

Вы заметите, что это сочетает в себе как параметр по умолчанию, так и проверку того, $servername имеет значение null, и если это так, пользователю предлагается ввести значение.

Вы можете запустить это из командной строки несколькими способами:

Он будет делать именно то, что вы думаете: использовать переданное в имени сервера значение HAL и среду по умолчанию Odyssey .

Но вы также можете запустить его как:

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

Существует еще один способ заставить пользователей вводить параметр, когда он является обязательным.

Сохраните следующее как Named_Parameters_Example_6.ps1

и запустите его следующим образом:

Вы заметите, что это заставляет вас вводить имя сервера, потому что вы сделали это обязательным, но по-прежнему используется имя среды по умолчанию Одиссея .

Вы также можете ввести параметр в командной строке:

И PowerShell не будет запрашивать имя сервера, поскольку оно уже есть.

Использование неизвестного количества аргументов

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

Например, сохраните следующий скрипт как Безымянные_Arguments_Example_4.ps1

Затем вызовите его следующим образом:

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

Одна попытка записать это с использованием именованных параметров может выглядеть так:

Как видите, это довольно быстро становится некрасивым, так как вам придется обрабатывать до 26 букв дисков.

К счастью, есть лучший способ справиться с этим, используя именованные параметры. Сохраните следующее как Named_Parameters_Example_7.ps1

Если вы хотите проверить свободное место на одном диске, вызовите его, как и следовало ожидать:

С другой стороны, если вы хотите протестировать несколько дисков, вы можете передать массив строк.

Это можно сделать одним из двух способов:

Обратите внимание, что буквы дисков разделены запятыми, а не пробелами. Это позволяет PowerShell понять, что это всего лишь один параметр. (Интересное примечание: если вы поставите пробел после запятой, он все равно будет обрабатывать список букв дисков как один параметр, запятая в основном съедает пространство.)

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