Powershell

Рабочие процессы Windows PowerShellWindows PowerShell Workflows

Рабочий процесс — это последовательность связанных программируемых операций, в ходе которых выполняются длительные задачи или скоординированные действия на нескольких устройствах или управляемых узлах.A workflow is a sequence of programmed, connected steps that perform long-running tasks or require the coordination of multiple steps across multiple devices or managed nodes. Преимущества рабочего процесса в сравнении с использованием обычного скрипта заключаются в возможности одновременного выполнения действия по отношению ко многим устройствам и в возможности автоматического восстановления при сбоях.The benefits of a workflow over a normal script include the ability to simultaneously perform an action against multiple devices and the ability to automatically recover from failures. Рабочий процесс Windows PowerShell представляет собой скрипт Windows PowerShell, который использует Windows Workflow Foundation.A Windows PowerShell Workflow is a Windows PowerShell script that leverages Windows Workflow Foundation. В то время как рабочий процесс прописан в синтаксисе Windows PowerShell и запускается Windows PowerShell, его обработка выполняется в Windows Workflow Foundation.While the workflow is written with Windows PowerShell syntax and launched by Windows PowerShell, it is processed by Windows Workflow Foundation.

Основная структураBasic Structure

Рабочий процесс Windows PowerShell начинается с ключевого слова рабочего процесса , за которым следует текст скрипта, заключенный в фигурные скобки.A Windows PowerShell Workflow starts with the Workflow keyword followed by the body of the script enclosed in braces. Имя рабочего процесса следует за ключевым словом Workflow , как это показано в следующем синтаксисе.The name of the workflow follows the Workflow keyword as shown in the following syntax. Имя рабочего процесса соответствует имени модуля Runbook службы автоматизации.The name of the workflow matches the name of the Automation runbook.

Чтобы добавить параметры в рабочий процесс, используйте ключевое слово param , как показано в следующем синтаксисе.To add parameters to the workflow, use the Param keyword as shown in the following syntax. Портал управления предложит пользователю предоставить значения этих параметров при запуске модуля runbook.The management Portal will prompt the user to provide values for these parameters when they start the runbook. В этом примере используется дополнительный атрибут Parameter, который указывает, обязателен ли этот параметр.This sample uses the optional Parameter attribute which specifies whether or not the parameter is mandatory.

ИменованиеNaming

Имя рабочего процесса должно соответствовать формату «глагол-существительное», принятому в Windows PowerShell.The name of the workflow should conform to the Verb-Noun format that is standard with Windows PowerShell. Список утвержденных глаголов для использования можно найти в статье Approved Verbs for Windows PowerShell Commands (Утвержденные глаголы для команд Windows PowerShell) .You can refer to Approved Verbs for Windows PowerShell Commands for a list of approved verbs to use. Имя рабочего процесса должно соответствовать имени модуля Runbook в службе автоматизации.The name of the workflow must match the name of the Automation runbook. При импорте модуля Runbook имя файла должно соответствовать имени рабочего процесса и должно заканчиваться на .ps1.If the runbook is being imported, then the filename must match the workflow name and must end in .ps1.

ОграниченияLimitations

Полный список ограничений и различий синтаксиса между Windows PowerShell и рабочими процессами Windows PowerShell см. в разделе Различия синтаксиса между сценариями и рабочими процессами сценариев.For a complete list of limitations and syntax differences between Windows PowerShell Workflows and Windows PowerShell, see Syntactic Differences Between Script Workflows and Scripts.

Создание файла сценария PowerShell

В Windows 10 файлы сценариев PowerShell можно создавать с помощью практически любого текстового редактора или консоли интегрированной среды сценариев (ISE).

Создание скрипта с помощью блокнота

Чтобы создать сценарий PowerShell с помощью блокнота, выполните следующие действия:

  1. Откройте приложение «Блокнот».
  2. Создайте или вставьте сценарий. Например: Write-Host ««Поздравляем! Ваш первый скрипт успешно выполнен»»

    Вышеприведенный скрипт просто выводит на экране фразу «Поздравляем! Ваш первый скрипт успешно выполнен».

  3. Сохраните файл под любым удобным названием, например, first_script.ps1

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

Кроме того, консоль PowerShell ISE можно использовать для кодирования сценариев в Windows 10. Интегрированная cреда сценариев является сложным инструментом, но вы можете начать работу с помощью этих шагов:

  1. Откройте системный поиск и введите запрос Windows PowerShell ISE, щелкните правой кнопкой мыши верхний результат, и выберите Запуск от имени администратора или выберите соответствующий параметр в правой колонке.
  2. В PowerShell ISE создайте пустой файл .ps1, в котором можно создать или вставить скрипт. Например:

    Write-Host ««Поздравляем! Ваш первый скрипт успешно выполнен»»

  3. Откройте меню Файл и нажмите кнопку Сохранить.
  4. Введите название сценария. Например, first_script_ise.ps1
  5. Сохраните скрипт.

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

Что способствовало появлению Windows PowerShell?

До появления PowerShell существовали (и существуют) следующие инструменты для автоматизации и администрирования сервисов: командная строка Windows и Windows Script Host. Но у этих технологий есть недостатки.

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

Большинство программных продуктов имеет консольный интерфейс, т.е. мы можем управлять программой, используя командную строку, при этом экономя ресурсы за счет отсутствия затрат на работу графического интерфейса. Компания Microsoft для серверной операционной системы Windows Server даже выпускает редакции без графического интерфейса (Server Core, в Windows Server 2019), но всего этого недостаточно, так как возможности командной строки ограничены, т.е. написать какую-то сложную логику для автоматизации чего-либо мы не сможем, а если и сможем, то на это нам потребуется время и знания.

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

Технология Windows Script Host позволяет выполнять все административные задачи, что и командная строка, включая их автоматизацию путем написания WSH скриптов, но здесь мы уже можем использовать полноценные языки программирования (VBScript и JScript), т.е. можно реализовывать сложную логику и алгоритмы. К тому же с помощью WSH мы управляем программными продуктами через объектный интерфейс, другими словами Windows Script Host намного «круче» чем командная строка. Но данная технология также не стала тем идеальным инструментом администрирования и автоматизации этого администрирования для системных администраторов, так как Windows Script Host требовал знаний вышеперечисленных языков программирования, что для системных администраторов на самом деле лишнее. Администраторам нужно всего лишь простой инструмент администрирования с возможностью запрограммировать какие-то действия, а углубляться в объектные модели программных продуктов на языках программирования VBScript и JScript им не хочется.

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

Жизненный цикл PowerShell Core 6.xLifecycle of PowerShell Core 6.x

В PowerShell Core используется политика современного жизненного цикла Майкрософт.PowerShell Core used the Microsoft Modern Lifecycle Policy. Этот жизненный цикл поддержки предназначен для предоставления клиентам актуальных версий.This support lifecycle is intended to keep customers up-to-date with the latest versions.

Ветвь PowerShell Core версии 6.x обновлялась примерно каждые шесть месяцев: 6.0, 6.1, 6.2 и т. д.The version 6.x branch of PowerShell Core was updated approximately once every six months (examples: 6.0, 6.1, 6.2, etc.). Однако после выхода PowerShell 7 больше не будет выпусков младшей версии 6.x.However, with the release of PowerShell 7, there won’t be anymore minor version releases of 6.x. Для PowerShell 6.2.x продолжат выходить обновления для обслуживания, пока поддержка не будет прекращена.PowerShell 6.2.x will continue to receive servicing updates while still supported.

Важно!

Чтобы продолжить получать поддержку, вам нужно обновить продукт в течение шести месяцев после выпуска версии с новым дополнительным номером.You must update within six months after each new minor version release to continue receiving support.

Например, если версия PowerShell Core 6.1 выпущена 1 июля 2018 г., чтобы продолжать получать поддержку, вам нужно выполнить обновление до версии PowerShell Core 6.1 к 1 января 2019 г.For example, if PowerShell Core 6.1 is released on July 1, 2018, you would be expected to update to PowerShell Core 6.1 by January 1, 2019 to maintain support.

Важно!

Кроме того, вам нужно обновлять продукт в течение 30 дней после выпуска версии с новым исправлением.You must update within 30 days after each new patch version release to continue receiving support.

Например, если вы используете PowerShell Core 6.1, а версия 6.1.3 выпущена 19 февраля 2019 г., вам нужно выполнить обновление до версии PowerShell Core 6.1.3 в течение 30 дней, т. е. до 21 марта 2019 г.For example, If you’re running PowerShell Core 6.1 and 6.1.3 was released on February 19, 2019, you would be expected to update to PowerShell Core 6.1.3 by March 21, 2019, which is 30 days after the release to maintain support. Если требуется какие-либо исправления, они будут включены в наше следующе накопительное обновление.If any fixes are found to be required, the fixes will be released in our next cumulative update.

Согласно политике современного жизненного цикла также требуется, чтобы корпорация Майкрософт предоставляла клиентам уведомление за 12 месяцев до прекращения поддержки продукта (например, PowerShell Core).The Modern Lifecycle Policy also requires that Microsoft give customers 12 months notice before discontinuing support for a product (that is, PowerShell Core).

Написание и запуск скриптов

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

Интенсив «Станьте хакером на Python за 3 дня»

16–18 ноября, Онлайн, Беcплатно

tproger.ru

События и курсы на tproger.ru

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

  • Restricted — выполнение скриптов запрещено. Стандартная конфигурация;
  • AllSigned — можно запускать скрипты, подписанные доверенным разработчиком; перед запуском скрипта PowerShell запросит у вас подтверждение;
  • RemoteSigned — можно запускать собственные скрипты или те, что подписаны доверенным разработчиком;
  • Unrestricted — можно запускать любые скрипты.

Для начала работы необходимо изменить настройку политики запуска на RemoteSigned, используя команду :

Командлеты

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

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

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

  • Get-Process — отобразить текущие процессы, запущенные на компьютере;
  • Get-Service — отобразить список служб и их статус;
  • Get-Content — отобразить содержимое указанного файла, например .

При необходимости список всех доступных командлетов можно вывести с помощью Get-Help-Category:

Также можно создавать и свои собственные командлеты.

Параметры

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

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

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

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

Конвейер

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

  • — сортировка запущенных служб по статусу;
  • — запись текста в файл.

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

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

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

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

Теперь, для вызова функции, требуется передавать два параметра:

При вызове функции мы передаем два обязательных параметра со значениями. Эти значения, внутри функции, будут доступны под названиями $param1 и $param2. Эти переменные мы передаем в команду получения и фильтрации логов.

Установка значений по умолчанию

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

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

Как видно на примере, если мы не указываем ключи param1 и param2 важна последовательность, так как именно в такой последовательности они будут присвоены переменным внутри функций.

Возвращение значений

В отличие от других языков, если мы присвоим переменной $result результат функции Get-DayLog, то она будет содержать значения:

Это будет работать до тех пор, пока мы не решим изменить функцию присвоив переменные:

Мы не можем получить результат используя переменную $result, так как функция не выводит информацию, а хранит ее в переменной $events. Вызывая $events мы тоже не получаем информацию, так как тут работает понятие «область видимости переменных».

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

Я бы рекомендовал всегда возвращать значения через return, а не использовать вывод используя команды типа Write-Output внутри функции. Использование return останавливает работу функции и возвращает значение, а это значит что его не стоит ставить по середине логики если так не планировалось.

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

Я вернул оба значения разделив их запятой. По умолчанию всегда возвращается массив. Массивы в Powershell это набор не именованных параметров. Более подробно  о них мы уже писали.

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

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

Подробно о хэш таблицах в Powershell вы можете почитать в предыдущих статьях. Далее так же будет несколько примеров с ними.

Вы можете возвращать любой тип данных и в любом формате и последовательности. Каждый из них имеет своё преимущество.

Область видимости переменных

Все переменные объявленные до момента вызова функции могут быть ей использованы:

Такой подход не запрещает переопределить переменную внутри функции дав ей другое значение:

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

Такие переменные называются глобальными. Объявляются приставкой $global:

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

Модули интеграцииIntegration Modules

Модуль интеграции — это пакет, который содержит модуль Windows PowerShell и может быть импортирован в службу автоматизации.An Integration Module is a package that contains a Windows PowerShell Module and can be imported into Automation. Модули Windows PowerShell содержат командлеты, которые можно использовать в модулях Runbook службы автоматизации.Windows PowerShell Modules contain cmdlets that can be used in Automation runbooks. Продукты и службы, такие как Operations Manager и Azure, обладают модулями, содержащими командлеты для их работы.Products and services such as Operations Manager and Azure have modules that include cmdlets specific to their operation.

Модули интеграции, импортированные в службу автоматизации, автоматически доступны для всех модулей Runbook.Integration Modules that are imported into Automation are automatically available to all runbooks. Поскольку Автоматизация основана на Windows PowerShell 4,0, она поддерживает автоматическую загрузку модулей, что позволяет использовать командлеты из установленных модулей, не импортируя их в скрипт с параметром Import-Module.Since Automation is based on Windows PowerShell 4.0, it supports auto loading of modules meaning that cmdlets from installed modules can be used without importing them into the script with Import-Module.

Любой модуль Windows PowerShell можно импортировать в службу автоматизации при условии, что все его зависимости могут находиться в одной папке.Any Windows PowerShell module can be imported into Automation as long as all of its dependencies can be located in a single folder. Если модуль зависит от параметров реестра или файлов, не находящиеся в пути по умолчанию, он может быть импортирован, но, скорее всего, не будет работать, так как автоматизация не сможет располагать свои зависимости.If the module depends on registry settings or files not in the default path, then it can be imported, but it will most likely not work because Automation will not be able to locate its dependencies. Модули с внешними зависимостями могут быть использованы в модулях runbook путем установи их на другой узел и доступа к ним из блока сценария .Modules with external dependencies can be used in a runbook by installing them on another host using and then accessing them with an script block.

С помощью Service Management Automation можно использовать модули с внешними зависимостями, установив их на каждом рабочем сервере.With Service Management Automation, you can use modules with external dependencies by installing them on each Worker server. Хотя командлеты в этих модулях можно использовать в модулях Runbook, они не будут обнаружены службой автоматизации для поддержки таких функций, как мастер вставки действия.While the cmdlets in these modules can be used in runbooks, they will not be discovered by Automation to support such features as the Insert Activity wizard. Чтобы использовать этот компонент, можно создать переносимый модуль, используя командлет New-SmaPortableModule .In order to use this feature, you can create a Portable module using the New-SmaPortableModule cmdlet. Этот командлет создает модуль, который включает заглушку для каждого командлета и может быть импортирован в службу автоматизации.This cmdlet creates a module that includes a stub for each of its cmdlets and can be imported into Automation. Когда модуль Runbook использует один из этих командлетов, заглушка перенаправляет вызов в фактический командлет внешнего модуля.When a runbook uses one of those cmdlets, the stub redirects the call to the actual cmdlet in the external module. Этот модуль необходимо установить на каждом сервере Worker, в противном случае произойдет сбой вызова.That module must be installed on each Worker server or the call will fail.

Поддержка сообществаCommunity Support

Мы также предлагаем поддержку сообщества на GitHub, где вы можете зарегистрировать вопрос, ошибку или запрос функции.We also offer community support on GitHub where you can file an issue, bug, or feature request.
Вы также можете получить помощь от других членов технического сообщества Microsoft PowerShell или на любом из форумов, перечисленных в разделе «Ресурсы сообщества» на странице центра документации по PowerShell.Also, you may find help from other members of the community in the Microsoft PowerShell Tech Community or any of the forums listed in the community section of PowerShell hub page. Но мы не можем гарантировать, что там вам оперативно помогут решить вашу проблему.We offer no guarantee there that the community will address or resolve your issue in a timely manner. Если ваша проблема требует немедленного вмешательства, следует использовать традиционные платные варианты поддержки.If you have a problem that requires immediate attention, you should use the traditional, paid support options.

Сценарии, функции и модули в Windows PowerShell

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

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

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

Важно!

По умолчанию выполнение сценариев в Windows запрещено! Для того чтобы посмотреть политику выполнения сценариев выполните командлет Get-ExecutionPolicy. В результате он вернет действующую политику, например:

  • Restricted – блокируется выполнение любых сценариев (значение по умолчанию);
  • AllSigned – разрешено выполнение сценариев, которые имеют цифровую подпись;
  • RemoteSigned – разрешено выполнение локальных сценариев, все скачанные сценарии должны иметь цифровую подпись;
  • Unrestricted — разрешено выполнение любых сценариев (не рекомендуется, так как небезопасно!).

Для разрешения выполнения сценариев необходимо использовать командлет Set-ExecutionPolicy с одним из вышеперечисленных параметров.

Например, для разрешения выполнения локальных сценариев выполним следующую команду, и согласимся с внесением изменений, нажав Y.

  
   Set-ExecutionPolicy RemoteSigned

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

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

Для этого необходимо указать ключевое слово Function и затем в фигурных скобках {} написать алгоритм работы этой функции, т.е. набор команд (например, какая-нибудь часто используемая процедура: создать пользователя с определенными правами, очистить определенные каталоги и так далее). Потом необходимо сохранить все это в сценарий, но только уже с расширением .psm1, так как этот файл будет являться уже модулем.

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

  
   Get-ChildItem Env:\PSModulePath | Format-Table -AutoSize

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

Поиск PowerShell в Windows 10, 8.1, 8.0 и 7Finding PowerShell in Windows 10, 8.1, 8.0, and 7

Иногда найти консоль или ISE (интегрированную среду сценариев) PowerShell в Windows бывает непросто, так как их расположение в разных версиях Windows отличается.Sometimes locating PowerShell console or the Integrated Scripting Environment (ISE) in Windows can be difficult, as its location moves from one version of Windows to the next.

Следующие таблицы помогут найти PowerShell в вашей версии Windows.The following tables should help you find PowerShell in your Windows version. Все указанные версии являются оригинальными, сразу после выпуска и без обновлений.All versions listed here are the original version, as released, with no updates.

КонсольFor Console

ВерсияVersion LocationLocation
Windows 10Windows 10 Щелкните значок Windows в левом нижнем углу и начните вводить PowerShell.Click left lower corner Windows icon, start typing PowerShell
Windows 8.1, 8.0Windows 8.1, 8.0 На начальном экране начните вводить PowerShell.On the start screen, start typing PowerShell.Если вы находитесь на рабочем столе, щелкните значок Windows в левом нижнем углу и начните вводить PowerShell.If on desktop, click left lower corner Windows icon, start typing PowerShell
Windows 7 с пакетом обновления 1 (SP1)Windows 7 SP1 Щелкните значок Windows в левом нижнем углу и в поле поиска начните вводить PowerShell.Click left lower corner Windows icon, on the search box start typing PowerShell

ISEFor ISE

ВерсияVersion LocationLocation
Windows 10Windows 10 Щелкните значок Windows в левом нижнем углу и начните вводить ISE.Click left lower corner Windows icon, start typing ISE
Windows 8.1, 8.0Windows 8.1, 8.0 На начальном экране введите PowerShell ISE.On the start screen, type PowerShell ISE.Если вы находитесь на рабочем столе, щелкните значок Windows в левом нижнем углу и введите PowerShell ISE.If on desktop, click left lower corner Windows icon, type PowerShell ISE
Windows 7 с пакетом обновления 1 (SP1)Windows 7 SP1 Щелкните значок Windows в левом нижнем углу и в поле поиска начните вводить PowerShell.Click left lower corner Windows icon, on the search box start typing PowerShell

Входные данные конвейераPipeline Input

Если требуется, чтобы функция принимала входные данные конвейера, необходимо написать дополнительный код.When you want your function to accept pipeline input, some additional coding is necessary. Как говорилось ранее в этой книге, команды могут принимать входные данные конвейера по значению (по типу) или по имени свойства.As mentioned earlier in this book, commands can accept pipeline input by value (by type) or by property name. Вы можете писать свои функции так же, как машинные команды, чтобы они принимали один тип входных данных или оба.You can write your functions just like the native commands so that they accept either one or both of these types of input.

Чтобы принимать входные данные конвейера по значению, укажите атрибут параметра для этого конкретного параметра.To accept pipeline input by value, specified the parameter attribute for that particular parameter. Помните, что входные данные конвейера по значению можно принимать только от одного из каждого типа данных.Keep in mind that you can only accept pipeline input by value from one of each datatype. Например, если есть два параметра, принимающих строковые входные данные, то только один из них может принимать входные данные конвейера по значению, так как, если это условие указано для обоих строковых параметров, входным данным конвейера будет неизвестно, к какому параметру следует выполнить привязку.For example, if you have two parameters that accept string input, only one of those can accept pipeline input by value because if you specified it for both of the string parameters, the pipeline input wouldn’t know which one to bind to. Это еще одна причина, по которой я называю этот тип входных данных конвейера по типу вместо по значению.This is another reason I call this type of pipeline input by type instead of by value.

Входные данные конвейера поступают в один элемент за раз аналогично тому, как элементы обрабатываются в цикле .Pipeline input comes in one item at a time similar to the way items are handled in a loop.
Если в качестве входных данных принимается массив, для обработки каждого из этих элементов требуется как минимум блок .At a minimum, a block is required to process each of these items if you’re accepting an array as input. Если в качестве входных данных принимается только одно значение, блок не требуется, но я по-прежнему рекомендую указывать его для обеспечения согласованности.If you’re only accepting a single value as input, a block isn’t necessary, but I still recommend specifying it for consistency.

Прием входных данных конвейера по имени свойства происходит аналогично, за исключением того, что указывается с помощью атрибута параметра и может быть указан для любого числа параметров независимо от типа данных.Accepting pipeline input by property name is similar except it’s specified with the parameter attribute and it can be specified for any number of parameters regardless of datatype. Ключевом момент в том, что выходными данными команды, в которую передается параметр, должно быть имя свойства, совпадающее с именем параметра или псевдонимом параметра вашей функции.The key is that the output of the command that’s being piped in has to have a property name that matches the name of the parameter or a parameter alias of your function.

Блоки и являются необязательными. and blocks are optional. указывается перед блоком и используется для выполнения всех начальных задач до получения элементов из конвейера. would be specified before the block and is used to perform any initial work prior to the items being received from the pipeline

Разобраться с этим очень важно.This is important to understand. Переданные значения недоступны в блоке .Values that are piped in are not accessible in the block

Блок указывается после блока и используется для очистки после обработки всех переданных элементов.The block would be specified after the block and is used for cleanup once all of the items that are piped in have been processed.

Оцените статью
Рейтинг автора
5
Материал подготовил
Андрей Измаилов
Наш эксперт
Написано статей
116
Добавить комментарий