Написание модуля Windows PowerShell
этот документ предназначен для администраторов, разработчиков скриптов и разработчиков командлетов, которым необходимо упаковать и распространить свои Windows PowerShell командлеты. с помощью модулей Windows PowerShell можно упаковывать и распространять решения Windows PowerShell, не используя скомпилированный язык.
Windows PowerShell модули позволяют секционировать, упорядочивать и структурировать код Windows PowerShell в автономные, многократно используемые единицы. С помощью этих многократно используемых модулей можно легко предоставить доступ к модулям напрямую другим пользователям. Если вы являетесь разработчиком скриптов, вы также можете повторно упаковать сторонние модули для создания пользовательских приложений на основе сценариев. Модули, аналогичные модулям в других языках сценариев, таких как Perl и Python, обеспечивают готовые к работе решения сценариев, использующие многократно используемые, распространяемые компоненты с дополнительным преимуществом, позволяющим переупаковать и составить абстрактные компоненты, чтобы создать пользовательские решения.
Библиотеки
Параметр Configuration
Модули можно использовать для настройки среды путем добавления конкретных командлетов, поставщиков, функций и переменных.
Разработка и распространение скомпилированного кода
Разработчики командлетов и поставщиков могут использовать модули для тестирования и распространения скомпилированного кода без необходимости создавать оснастки. Они могут импортировать сборку, содержащую скомпилированный код, в виде модуля (двоичный модуль) без необходимости создавать и регистрировать оснастки.
Установка модуля PowerShell
После создания модуля PowerShell вы, вероятно, захотите установить модуль в системе, чтобы его могли использовать не только вы, но и другие пользователи. В целом, этот процесс включает копирование файлов модулей (файлы PSM1 или двоичной сборки, манифеста модуля и другие связанные файлы) в каталог на этом компьютере. Для очень маленького проекта это может быть просто копирование и вставка файлов с помощью проводника Windows на один удаленный компьютер. Но для более крупных решений может потребоваться более сложный процесс установки. Независимо от того, как вы устанавливаете модуль в системе, PowerShell поддерживает ряд методов, с помощью которых пользователи могут находить и использовать ваши модули. Следовательно, основная задача установки — сделать так, чтобы ваш модуль был доступным для PowerShell. Дополнительные сведения см. в статье Импорт модуля PowerShell.
Правила установки модулей
Следующие сведения относятся ко всем модулям, включая модули, созданные для собственного использования, получаемые от других сторон и предоставляемые другим пользователям.
Установка модулей в PSModulePath
По возможности устанавливайте все модули по пути, указанному в переменной среды PSModulePath, или добавьте путь к модулю в значение переменной среды PSModulePath.
По умолчанию значение переменной среды PSModulePath содержит следующие системные и пользовательские каталоги модулей, но вы можете добавлять и изменять это значение.
Это расположение зарезервировано для модулей, поставляемых с Windows. Не устанавливайте модули в это расположение.
Чтобы получить значение переменной среды PSModulePath, используйте одну из следующих команд.
Чтобы добавить путь к модулю в значение переменной среды PSModulePath, используйте следующий формат команды. В этом формате используется метод SetEnvironmentVariable класса System.Environment, чтобы сделать изменение переменной среды PSModulePath независимым от сеанса.
Использование правильного имени каталога модулей
Модуль с правильным форматом — это модуль, хранящийся в каталоге, имя которого совпадает с базовым именем хотя бы одного файла в каталоге модуля. Если формат модуля неправильный, Windows PowerShell не распознает его как модуль.
Базовое имя файла — это имя файла без расширения. В модуле с правильным форматом имя каталога, содержащего файлы модулей, должно совпадать с базовым именем хотя бы одного файла в модуле.
Например, в примере модуля Fabrikam каталог, содержащий файлы модулей, называется Fabrikam, и хотя бы один файл имеет базовое имя Fabrikam. В этом случае и Fabrikam.psd1, и Fabrikam.dll имеют базовое имя Fabrikam.
Результат неправильной установки
Если модуль имеет неправильный формат и его расположение не включено в значение переменной среды PSModulePath, основные функции обнаружения Windows PowerShell, описанные ниже, не будут работать.
Функция автоматической загрузки модуля не сможет автоматически импортировать модуль.
Параметр ListAvailable командлета Get-Module не сможет найти модуль.
Командлет Import-Module не сможет найти модуль. Чтобы импортировать модуль, необходимо указать полный путь к файлу корневого модуля или файлу манифеста модуля.
Дополнительные функции, описанные ниже, не будут работать, если модуль не импортируется в сеанс. В модулях с правильным форматом в переменной среды PSModulePath эти функции будут работать, даже если модуль не импортируется в сеанс.
Командлет Get-Command не сможет найти команды в модуле.
Командлеты Update-Help и Save-Help не смогут обновить или сохранить справку для модуля.
Командлет Show-Command не сможет найти и отобразить команды в модуле.
Команды в модуле будут отсутствовать в окне Show-Command в интегрированной среде скриптов Windows PowerShell (ISE).
Расположение для установки модулей
В этом разделе описывается, где в файловой системе устанавливаются модули Windows PowerShell. Расположение зависит от того, как используется модуль.
Установка модулей для определенного пользователя
Если вы создаете собственный модуль или получаете модуль от другой стороны, например с веб-сайта сообщества Windows PowerShell, и вам нужно, чтобы модуль был доступен только для вашей учетной записи пользователя, установите модуль в пользовательском каталоге модулей.
Этот каталог добавляется в значение переменной среды PSModulePath по умолчанию.
Установка модулей для всех пользователей в программных файлах
Если вам нужно, чтобы модуль был доступен для всех учетных записей пользователей на компьютере, установите модуль в папку с программными файлами.
Это расположение добавляется в значение переменной среды PSModulePath по умолчанию в Windows PowerShell 4.0 и более поздних версиях. Для более ранних версий Windows PowerShell можно вручную создать расположение программных файлов (%ProgramFiles%\WindowsPowerShell\Modules) и добавить этот путь в переменную среды PSModulePath, как описано выше.
Установка модулей в каталоге продукта
Если вы предоставляете модуль другим сторонам, используйте каталог с программными файлами по умолчанию, как описано выше, или создайте собственный подкаталог для компании или продукта в каталоге %ProgramFiles%.
Например вымышленная компания Fabrikam Technologies предоставляет модуль Windows PowerShell для своего продукта Fabrikam Manager. Установщик модуля создает подкаталог Modules в подкаталоге продукта Fabrikam Manager.
Чтобы включить функции обнаружения модулей Windows PowerShell для поиска модуля Fabrikam, установщик модуля Fabrikam добавляет расположение модуля в значение переменной среды PSModulePath.
Установка модулей в каталоге с общими файлами
Если модуль используется несколькими компонентами или версиями продукта, установите модуль в подкаталог для модуля в подкаталоге %ProgramFiles%\Common Files\Modules.
Затем установщик проверяет, что значение переменной среды PSModulePath содержит путь к подкаталогу модуля с общими файлами.
Установка нескольких версий модуля
Чтобы установить несколько версий одного модуля, выполните следующую процедуру.
Чтобы импортировать определенную версию модуля, пользователь может использовать параметры MinimumVersion или RequiredVersion командлета Import-Module.
Например, если модуль Fabrikam доступен в версиях 8.0 и 9.0, структура каталогов модуля Fabrikam может выглядеть следующим образом:
Установщик добавляет оба пути к модулю в значение переменной среды PSModulePath.
После выполнения этих действий параметр ListAvailable командлета Get-Module получает оба модуля Fabrikam. Чтобы импортировать определенный модуль, используйте параметры MinimumVersion или RequiredVersion командлета Import-Module.
Если оба модуля, которые содержат командлеты с одинаковыми именами, импортируются в один сеанс, в этом сеансе будут доступными командлеты, импортированные последними.
Обработка конфликтов имен команд
Конфликты имен команд могут возникать, когда команды, экспортируемые модулем, имеют те же имена, что и команды в сеансе пользователя.
Если сеанс содержит две команды с одинаковым именем, Windows PowerShell выполняет команду согласно приоритету по типу. Если сеанс содержит две команды с одинаковыми именем и типом, Windows PowerShell выполняет команду, которая была добавлена в сеанс последней. Чтобы выполнить команду, которая не выполняется по умолчанию, пользователи могут определить ее имя, используя имя модуля.
Чтобы предотвратить конфликты имен, авторы модулей могут использовать ключ DefaultCommandPrefix в манифесте модуля, чтобы указать префикс существительного для всех команд, экспортируемых из модуля.
поддержка путей в системах, отличных от Windows
неWindowsные платформы используют символ двоеточия ( : ) в качестве разделителя пути и символ прямой косой черты ( / ) в качестве разделителя каталогов. [System.IO.Path] Класс имеет статические члены, которые можно использовать для того, чтобы код работал на любой платформе:
; При создании строк пути используйте эти статические свойства вместо \ символов и.
about_Modules
Short description
Explains how to install, import, and use PowerShell modules.
Long description
A module is a package that contains PowerShell members, such as cmdlets, providers, functions, workflows, variables, and aliases.
People who write commands can use modules to organize their commands and share them with others. People who receive modules can add the commands in the modules to their PowerShell sessions and use them just like the built-in commands.
This topic explains how to use PowerShell modules. For information about how to write PowerShell modules, see Writing a PowerShell Module.
What Is a Module?
A module is a package that contains PowerShell members, such as cmdlets, providers, functions, workflows, variables, and aliases. The members of this package can be implemented in a PowerShell script, a compiled DLL, or a combination of both. These files are usually grouped together in a single directory. For more information, see Understanding a Windows PowerShell Module in the SDK documentation.
Module Auto-Loading
Beginning in PowerShell 3.0, PowerShell imports modules automatically the first time that you run any command in an installed module. You can now use the commands in a module without any set-up or profile configuration, so there’s no need to manage modules after you install them on your computer.
The commands in a module are also easier to find. The Get-Command cmdlet now gets all commands in all installed modules, even if they are not yet in the session. You can find a command and use it without importing needing to import the module first.
Get Help for the Command
Get-Command commands that include a wildcard character ( * ) are considered to be for discovery, not use, and do not import any modules.
Only modules that are stored in the location specified by the PSModulePath environment variable are automatically imported. Modules in other locations must be imported by running the Import-Module cmdlet.
Also, commands that use PowerShell providers do not automatically import a module. For example, if you use a command that requires the WSMan: drive, such as the Get-PSSessionConfiguration cmdlet, you might need to run the Import-Module cmdlet to import the Microsoft.WSMan.Management module that includes the WSMan: drive.
How to Use a Module
To use a module, perform the following tasks:
This topic explains how to perform these tasks. It also includes other useful information about managing modules.
How to Install a Module
If you receive a module as a folder with files in it, you need to install it on your computer before you can use it in PowerShell.
Most modules are installed for you. PowerShell comes with several preinstalled modules, sometimes called the core modules. On Windows-based computers, if features that are included with the operating system have cmdlets to manage them, those modules are preinstalled. When you install a Windows feature, by using, for example, the Add Roles and Features Wizard in Server Manager, or the Turn Windows features on or off dialog box in Control Panel, any PowerShell modules that are part of the feature are installed. Many other modules come in an installer or Setup program that installs the module.
Use the following command to create a Modules directory for the current user:
Copy the entire module folder into the Modules directory. You can use any method to copy the folder, including Windows Explorer and Cmd.exe, as well as PowerShell. In PowerShell use the Copy-Item cmdlet. For example, to copy the MyModule folder from C:\ps-test\MyModule to the Modules directory, type:
You can install a module in any location, but installing your modules in a default module location makes them easier to manage. For more information about the default module locations, see the Module and DSC Resource Locations, and PSModulePath section.
How to Find Installed Modules
To find modules that are installed in a default module location, but not yet imported into your session, type:
To find the modules that have already been imported into your session, at the PowerShell prompt, type:
For more information about the Get-Module cmdlet, see Get-Module.
How to Find the Commands in a Module
Use the Get-Command cmdlet to find all available commands. You can use the parameters of the Get-Command cmdlet to filter commands such as by module, name, and noun.
To find all commands in a module, type:
For example, to find the commands in the BitsTransfer module, type:
For more information about the Get-Command cmdlet, see Get-Command.
How to Get Help for the Commands in a Module
If the module contains Help files for the commands that it exports, the Get-Help cmdlet will display the Help topics. Use the same Get-Help command format that you would use to get help for any command in PowerShell.
Beginning in PowerShell 3.0, you can download Help files for a module and download updates to the Help files so they are never obsolete.
To get help for a commands in a module, type:
To get help online for command in a module, type:
To download and install the help files for the commands in a module, type:
For more information, see Get-Help and Update-Help.
How to Import a Module
You might also choose to import a module so that you can use the parameters of the Import-Module command, such as the Prefix parameter, which adds a distinctive prefix to the noun names of all imported commands, or the NoClobber parameter, which prevents the module from adding commands that would hide or replace existing commands in the session.
To import modules, use the Import-Module cmdlet.
To import modules in a PSModulePath location into the current session, use the following command format.
For example, the following command imports the BitsTransfer module into the current session.
To import a module that is not in a default module location, use the fully qualified path to the module folder in the command.
For example, to add the TestCmdlets module in the C:\ps-test directory to your session, type:
To import a module file that is not contained in a module folder, use the fully qualified path to the module file in the command.
For example, to add the TestCmdlets.dll module in the C:\ps-test directory to your session, type:
For more information about adding modules to your session, see Import-Module.
How to Import a Module into Every Session
The Import-Module command imports modules into your current PowerShell session. To import a module into every PowerShell session that you start, add the Import-Module command to your PowerShell profile.
For more information about profiles, see about_Profiles.
How to Remove a Module
When you remove a module, the commands that the module added are deleted from the session.
To remove a module from your session, use the following command format.
For example, the following command removes the BitsTransfer module from the current session.
Removing a module reverses the operation of importing a module. Removing a module does not uninstall the module. For more information, see Remove-Module.
Module and DSC Resource Locations, and PSModulePath
These folders contain modules that ship with Windows and PowerShell.
User-specific modules: These are modules installed by the user in the user’s scope. Install-Module has a Scope parameter that allows you to specify whether the module is installed for the current user or for all users. For more information, see Install-Module.
The user-specific CurrentUser location on Windows is the PowerShell\Modules folder located in the Documents location in your user profile. The specific path of that location varies by version of Windows and whether or not you are using folder redirection. Microsoft OneDrive can also change the location of your Documents folder.
To view the default module locations, type:
To add a default module location, use the following command format.
The semi-colon ( ; ) in the command separates the new path from the path that precedes it in the list.
For example, to add the C:\ps-test\Modules directory, type:
To add a default module location on Linux or MacOS, use the following command format:
For example, to add the /usr/local/Fabrikam/Modules directory to the value of the PSModulePath environment variable, type:
On Linux or MacOS, the colon ( : ) in the command separates the new path from the path that precedes it in the list.
When you add a path to PSModulePath, Get-Module and Import-Module commands include modules in that path.
The value that you set affects only the current session. To make the change persistent, add the command to your PowerShell profile or use System in Control Panel to change the value of the PSModulePath environment variable in the registry.
Also, to make the change persistent, you can also use the SetEnvironmentVariable method of the System.Environment class to add a Path to the PSModulePath environment variable.
For more information about the PSModulePath variable, see about_Environment_Variables.
Modules and Name Conflicts
Name conflicts occur when more than one command in the session has the same name. Importing a module causes a name conflict when commands in the module have the same names as commands or items in the session.
Name conflicts can result in commands being hidden or replaced.
Hidden
A command is hidden when it is not the command that runs when you type the command name, but you can run it by using another method, such as by qualifying the command name with the name of the module or snap-in in which it originated.
Replaced
A command is replaced when you cannot run it because it has been overwritten by a command with the same name. Even when you remove the module that caused the conflict, you cannot run a replaced command unless you restart the session.
Import-Module might add commands that hide and replace commands in the current session. Also, commands in your session can hide commands that the module added.
To detect name conflicts, use the All parameter of the Get-Command cmdlet. Beginning in PowerShell 3.0, Get-Command gets only that commands that run when you type the command name. The All parameter gets all commands with the specific name in the session.
To prevent name conflicts, use the NoClobber or Prefix parameters of the Import-Module cmdlet. The Prefix parameter adds a prefix to the names of imported commands so that they are unique in the session. The NoClobber parameter does not import any commands that would hide or replace existing commands in the session.
You can also use the Alias, Cmdlet, Function, and Variable parameters of Import-Module to select only the commands that you want to import, and you can exclude commands that cause name conflicts in your session.
Module authors can prevent name conflicts by using the DefaultCommandPrefix property of the module manifest to add a default prefix to all command names. The value of the Prefix parameter takes precedence over the value of DefaultCommandPrefix.
Even if a command is hidden, you can run it by qualifying the command name with the name of the module or snap-in in which it originated.
The PowerShell command precedence rules determine which command runs when the session includes commands with the same name.
For example, when a session includes a function and a cmdlet with the same name, PowerShell runs the function by default. When the session includes commands of the same type with the same name, such as two cmdlets with the same name, by default, it runs the most recently added command.
For more information, including an explanation of the precedence rules and instructions for running hidden commands, see about_Command_Precedence.
Modules and Snap-ins
You can add commands to your session from modules and snap-ins. Modules can add all types of commands, including cmdlets, providers, and functions, and items, such as variables, aliases, and PowerShell drives. Snap-ins can add only cmdlets and providers.
Before removing a module or snap-in from your session, use the following commands to determine which commands will be removed.
To find the source of a cmdlet in your session, use the following command format:
For example, to find the source of the Get-Date cmdlet, type:
Module-related Warnings and Errors
The commands that a module exports should follow the PowerShell command naming rules. If the module that you import exports cmdlets or functions that have unapproved verbs in their names, the Import-Module cmdlet displays the following warning message.
WARNING: Some imported command names include unapproved verbs which might make them less discoverable. Use the Verbose parameter for more detail or type Get-Verb to see the list of approved verbs.
This message is only a warning. The complete module is still imported, including the non-conforming commands. Although the message is displayed to module users, the naming problem should be fixed by the module author.
To suppress the warning message, use the DisableNameChecking parameter of the Import-Module cmdlet.
Built-in Modules and Snap-ins
In PowerShell 2.0 and in older-style host programs in PowerShell 3.0 and later, the core commands that are installed with PowerShell are packaged in snap-ins that are added automatically to every PowerShell session.
Beginning in PowerShell 3.0, for host programs that implement the InitialSessionState.CreateDefault2 initial session state API the Microsoft.PowerShell.Core snap-in is added to every session by default. Modules are loaded automatically on first-use.
Remote sessions, including sessions that are started by using the New-PSSession cmdlet, are older-style sessions in which the built-in commands are packaged in snap-ins.
The following modules (or snap-ins) are installed with PowerShell.
Logging Module Events
Что такое Windows PowerShell и с чем его едят? Часть 1: основные возможности
Исторически утилиты командной строки в Unix-системах развиты лучше чем в Windows, однако с появлением нового решения ситуация изменилась.
Windows PowerShell позволяет системным администраторам автоматизировать большинство рутинных задач. С ее помощью можно менять настройки, останавливать и запускать сервисы, а также производить обслуживание большинства установленных приложений. Воспринимать синее окошко как еще один интерпретатор команд было бы неправильно. Такой подход не отражает сути предложенных корпорацией Microsoft инноваций. На самом деле возможности Windows PowerShell гораздо шире: в небольшом цикле статей мы попробуем разобраться, чем решение Microsoft отличается от более привычных нам средств.
Основные возможности
Windows PowerShell позволяет:
Оболочка и среда разработки
Существует Windows PowerShell в двух ипостасях: помимо эмулятора консоли с командной оболочкой есть интегрированная среда сценариев (Integrated Scripting Environment — ISE). Чтобы получить доступ к интерфейсу командной строки достаточно выбрать соответствующий ярлык в меню Windows или запустить powershell.exe из меню «Выполнить». На экране появится синее окошко, заметно отличающееся по возможностям от допотопного cmd.exe. Там есть автодополнение и другие фишки, привычные пользователям командных оболочек для Unix-систем.
Для работы с оболочкой нужно запомнить некоторые сочетания клавиш:
Windows PowerShell ISE является полноценной средой разработки с поддерживающим вкладки и подсветку синтаксиса редактором кода, конструктором команд, встроенным отладчиком и другими программистскими радостями. Если в редакторе среды разработки после имени команды написать знак дефис, вы получите в выпадающем списке все доступные параметры с указанием типа. Запустить PowerShell ISE можно либо через ярлык из системного меню, либо с помощью исполняемого файла powershell_ise.exe.
Командлеты
Помимо Get в командлетах для обозначения действий используются и другие глаголы (и не только глаголы, строго говоря). В списке ниже мы приведем несколько примеров:
Add — добавить;
Clear — очистить;
Enable — включить;
Disable — выключить;
New — создать;
Remove — удалить;
Set — задать;
Start — запустить;
Stop — остановить;
Export — экспортировать;
Import — импортировать.
Есть системные, пользовательские и опциональные командлеты: в результате выполнения все они возвращают объект или массив объектов. К регистру они не чувствительны, т.е. с точки зрения интерпретатора команд нет разницы между Get-Help и get-help. Для разделения используется символ ‘;’, но ставить его обязательно только если в одной строке выполняется несколько командлетов.
Командлеты Windows PowerShell группируются в модули (NetTCPIP, Hyper-V и т.д.), а для поиска по объекту и действию существует командлет Get-Command. Показать справку по нему можно так:
Справка в Windows PowerShell обновляется командлетом Update-Help. Если строка команд получается слишком длинной, аргументы командлета можно перенести на следующую, написав служебный символ ‘`’ и нажав Enter — просто закончить писать команду на одной строке и продолжить на другой не получится.
Ниже приведем несколько примеров распространенных командлетов:
Get-Process — показать запущенные в системе процессы;
Get-Service — показать службы и их статус;
Get-Content — вывести содержимое файла.
Для часто используемых командлетов и внешних утилит в Windows PowerShell есть короткие синонимы — алиасы (от англ. Alias). Например, dir — алиас Get-ChildItem. Есть в списке синонимов и аналоги команд из Unix-систем (ls, ps и т.д.), а командлет Get-Help вызывается командой help. Полный список синонимов можно посмотреть с помощью командлета Get-Alias:
Сценарии, функции, модули и язык PowerShell
Restricted — запуск сценариев запрещен (по умолчанию);
AllSigned — разрешен только запуск подписанных доверенным разработчиком сценариев;
RemoteSigned — разрешен запуск подписанных и собственных сценариев;
Unrestricted — разрешен запуск любых сценариев.
У администратора есть два варианта действий. Наиболее безопасный предполагает подписание скриптов, но это довольно серьезное колдунство — мы будем разбираться с ним в следующих статьях. Сейчас пойдем по пути наименьшего сопротивления и поменяем политику:
PowerShell для этого придется запустить от имени администратора, хотя с помощью специального параметра можно изменить политику и для текущего пользователя.
Пишутся скрипты на объектно-ориентированном языке программирования, команды которого именуются по тому же принципу, что и рассмотренные ранее командлеты: «Действие-Объект» («Глагол-Существительное»). Основное его предназначение — автоматизация задач администрирования, но это полноценный интерпретируемый язык, в котором есть все необходимые конструкции: условный переход, циклы, переменные, массивы, объекты, обработка ошибок и т.д. Для написания сценариев годится любой текстовый редактор, но удобнее всего запустить Windows PowerShell ISE.
Конвейеры
В последнем примере мы применили знакомую пользователям оболочек для Unix-систем конструкцию. В Windows PowerShell вертикальная черта также позволяет передать выход одной команды на вход другой, но в реализации конвейера есть и существенная разница: речь здесь идет уже не о наборе символов или каком-то тексте. Встроенные командлеты или пользовательские функции возвращают объекты или массивы объектов, а также могут получать их на входе. Как в Bourne shell и его многочисленных последователях, в PowerShell с помощью конвейера упрощается выполнение сложных задач.
Простейший пример конвейера выглядит так:
Сначала выполняется командлет Get-Service, а потом все полученные им службы передаются на сортировку по свойству Status командлету Sort-Object. В какой именно аргумент передается результат работы предыдущего участка конвейера, зависит от его типа — обычно это InputObject. Подробнее этот вопрос будет рассматриваться в посвященной языку программирования PowerShell статье.
При желании цепочку можно продолжить и передать результат работы Sort-Object еще одному командлету (выполняться они будут слева направо). Кстати, пользователям Windows доступна и привычная всем юниксоидам конструкция для постраничного вывода:
Запуск задач в фоновом режиме
Довольно часто бывает нужно запустить некую команду в фоне, чтобы не дожидаться результата ее выполнения в сессии оболочки. В Windows PowerShell есть несколько командлетов на такой случай:
Start-Job — запуск фоновой задачи;
Stop-Job — остановка фоновой задачи;
Get-Job — просмотр списка фоновых задач;
Receive-Job — просмотр результата выполнения фоновой задачи;
Remove-Job — удаление фоновой задачи;
Wait-Job — перевод фоновой задачи обратно в консоль.
Для запуска фоновой задачи мы используем командлет Start-Job и в фигурных скобках указываем команду или набор команд:
Фоновыми задачами в Windows PowerShell можно манипулировать, зная их имена. Для начала научимся их отображать:
Теперь покажем результат работы задания Job1:
Всё довольно просто.
Удаленное выполнение команд
Windows PowerShell позволяет выполнять команды и сценарии не только на локальном, но и на удаленном компьютере и даже на целой группе машин. Для этого существует несколько способов:
Версии PowerShell
Также можно воспользоваться командлетом:
То же самое делается и с помощью командлета Get-Host. На самом деле вариантов множество, но для их применения нужно изучить язык программирования PowerShell, чем мы и займемся в следующей статье.