
Функції, фільтри, сценарії та модулі в PowerShell відкривають широкі можливості для розробників та системних адміністраторів. Ці концепції є важливими складовими мови PowerShell, дозволяючи створювати ефективні та повторно використовувані скрипти, забезпечуючи легкість управління та обробки даних. У нашому збагаченому посібнику про функції, фільтри, сценарії та модулі в PowerShell, ми розкриємо всі аспекти цих концепцій. Функції дозволяють групувати код та забезпечують зручний спосіб використання його у різних частинах програми. Фільтри дають можливість обробки даних за певними умовами, спрощуючи виконання складних завдань. Сценарії дозволяють виконувати послідовність команд у зручному та форматі.
Однак особливий акцент буде зроблений на модулях в PowerShell – потужних інструментах, які дозволяють створювати незалежні та високоякісні програмні компоненти. Модулі сприяють організації коду, забезпечують його перевикористовування та дозволяють створювати власні зручні пакети функцій. Завдяки нашому посібнику ви дізнаєтесь про різні типи функцій, створення та використання фільтрів, роботу з сценаріями та налаштування модулів. Ми надамо зразки коду та практичні вправи, що допоможуть вам усвідомити ці концепції та стати більш впевненими у використанні PowerShell. Розкрийте всі можливості функцій, фільтрів, сценаріїв та модулів в PowerShell та розвивайте свої навички програмування з нашим повним посібником. Вдосконалюйте ваші скрипти, забезпечуйте швидкі та ефективні операції, та здійснюйте зручне управління даними в середовищі Windows.
Досі ми працювали переважно зі стандартними скомпільованими командлетами, функціональність яких ми не можемо змінити, оскільки їх вихідний код недоступний у PowerShell. Функції та сценарії – це два інших типи команд PowerShell, які можна створювати та змінювати на свій розсуд за допомогою мови PowerShell.
Відразу варто відзначити, що функції в PowerShell мають деякі особливості в порівнянні з функціями в традиційних мовах програмування, тому що PowerShell – це в першу чергу оболонка. У традиційних мовах функція зазвичай аналогічна об’єктному методу, а в PowerShell функція є командою. Звідси різниця в тому, як викликаються функції і передаються їм аргументи.
Зазвичай функції в традиційних мовах повертають єдине значення того чи іншого типу. Значенням функції PowerShell може бути масив різних об’єктів, оскільки кожен вираз, обчислений у функції, поміщає свій результат у вихідний потік.
Крім того, функції в PowerShell поділяються на кілька типів відповідно до їх поведінки всередині командного конвеєра.
Тому, щоб грамотно працювати в оболонці і писати коректні програми в PowerShell, необхідно розглянути питання, пов’язані з реалізацією функцій і скриптів в даній системі.
Нагадаємо, що функція в PowerShell – це блок коду, який має ім’я і знаходиться в пам’яті до закінчення поточного сеансу оболонки. Якщо функція визначається без формальних параметрів, то для її визначення досить вказати ключове слово функції, потім ім’я функції і список виразів, укладених в фігурні дужки, складові тіло функції. Наприклад, створимо функцію MuEips:
PS С:\> function MyFunc {"Всем привет!") PS С:\> Для вызова этой функции нужно просто ввести ее имя: PS С:\> MyFunc Всем привет! Отметим, что во многих языках программирования при вызове функции после ее имени нужно указывать круглые скобки. В PowerShell этого делать нельзя, возникнет ошибка: PS С:\> MyFunc() строка:1 знак:8 + MyFunc() + После ’’(’' ожидалось выражение. + Categoryinfo : ParserError: (:) [], ParentContainsErrorRecordException + FullyQualifiedErrorld : ExpectedExpression
Це пояснюється тим, що остання команда інтерпретується оболонкою як виклик функції MyFunc з аргументом (). Дужки в PowerShell вказують на результат обчислення виразу або масиву, тому система очікує, що в дужках буде вказано вираз або перераховані елементи масиву, а там нічого немає. Тому виникає помилка, адже для того, щоб правильно оголосити порожній масив в PowerShell, потрібно перед дужками поставити знак e.
Функції можуть працювати з аргументами, які передаються їм при запуску, причому підтримуються два варіанти обробки таких аргументів: за допомогою змінної $args і через опис формальних параметрів.
Функція в PowerShell має доступ до аргументів, з якими її було запущено, навіть якщо під час визначення цієї функції не було вказано жодних формальних параметрів. Всі фактичні аргументи функції автоматично зберігаються в змінній $args. Іншими словами, змінна $args містить масив, елементами якого є параметри функції, задані при її запуску. Наприклад, додамо змінну $args до нашої функції Murips:
PS С:\> function MyFunc {"Привет, $args!"}
Оскільки змінна $args поміщена в рядок в подвійні лапки, при запуску функції значення цієї змінної буде обчислено (розгорнуто) і результат буде вставлений в рядок.
Назвемо функцію MyFunc з трьома параметрами:
PS С:\> MyFunc Андреи Сергей Иван Привет, Андрей Сергей Иван!
Як бачите, три зазначені нами параметри (три елементи $args масиву) поміщаються у вихідний рядок і розділяються пробілами. Ви можете змінити символ, який розділяє елементи масивів при їх підстановці в рядки, що розширюються, змінивши значення спеціальної змінної $OFS:
PS С:\> function MyFunc { » $OFS = "," » "Привет, $args!"} » PS C:\> MyFunc Андреи Сергеи Иван Привет, Андрей,Сергей,Иван!
Знову ж таки, зверніть увагу, що, на відміну від традиційних мов програмування, функції в PowerShell є командами (вони не є об’єктними методами!), тому їх аргументи розділені пробілом без дужок, що розділяють коми, і без цитування рядків символів. Щоб переконатися в цьому, запустимо функцію Murips звичайним для інших мов програмування способом:
PS С:\> MyFunc("Андрей", "Сергей", "Иван") Привет, System.Object[]!
Нагадаємо, що масиви в PowerShell задаються шляхом перерахування їх елементів, а дужки, що оточують вираз, вказують на те, що вираз потрібно обчислити. Тому помилки при такому виклику функції немає, але в цьому випадку функції Муріпса передаються не три символьних аргументи, а один аргумент, що представляє собою масив з трьох елементів!
Оскільки змінна $args масиву, всередині функції можна отримати доступ до окремих аргументів за їх порядковим номером (не забувайте, що нумерація елементів масиву починається з нуля), і використовувати властивість Count of the Length для визначення загальної кількості аргументів, переданих функції.
Наприклад, створимо функцію SumArgs, яка повідомить кількість своїх аргументів і обчислить їх суму:
PS С:\> function SumArgs{"Количество аргументов: $($args.count)" » $n = О » for($i =0; $i -It $args.count; $i++) { $n += $args[$i] } » "Сумма аргументов: $n") » PS C:\> Вызовем функцию SumArgs с тремя числовыми аргументами: PS C:\> SumArgs 123 Количество аргументов: 3 Сумма аргументов: 6
Крім масиву $args, PowerShell підтримує більш звичний і зручний підхід до обробки аргументів функції шляхом установки формальних параметрів.
У PowerShell, як і в більшості інших мов програмування, при описі функції можна задати список формальних параметрів, значення яких будуть замінені значеннями фактичних аргументів, переданих під час виконання функції.
При цьому список формальних параметрів може бути заданий в круглих дужках після імені функції (саме так описуються параметри функцій в більшості мов програмування) або всередині самої функції за допомогою спеціального оператора Param.
Визначимо, наприклад, функцію віднімання, щоб знайти різницю між двома її аргументами (параметру $from відповідає зменшуваний, параметру $count відповідає віднімається параметр): PS C: \> functxon відняти ($frcm, $count) {$from – $cotmt}
Коли викликається функція віднімання, її формальні параметри замінюються фактичними аргументами, ідентифікованими за позицією в командному рядку або за назвою.
Например: PS С:\> subtract 10 2 8 В этом случае соответствие формальных параметров фактически переданным аргументам определяется по позиции: вместо первого параметра $from подставляется число 10, вместо второго параметра $count подставляется число 2. При указании аргументов можно использовать имена формальных параметров, порядок указания аргументов при этом становится несущественным. Например: PS С:\> subtract -from 10 -count 2 8 PS C:\> subtract -count 3 -from 5 2 Если дважды указать имя одного и того же параметра, то возникнет ошибка: PS С:\> subtract -from 10 -from 2 subtract : He удается привязать параметр, т. к. параметр "from” указан более одного раза. Для указания множественных значений параметров, допускающих множественные значения, используйте синтаксис массива. Например, "-parameter valuel,value2,value3". строка:1 знак:19 + subtract -from 10 -from 2 + — + Categoryinfo : InvalidArgument: (:) [subtract], ParameterBindingException + FullyQualifiedErrorld : ParameterAlreadyBound,subtract
При виклику функції можливий і третій варіант вказівки аргументів, коли комусь даються імена, а деякі визначаються позицією в командному рядку.
В цьому випадку застосовується наступний алгоритм:
Всі іменовані аргументи зіставляються з відповідними формальними параметрами і видаляються зі списку аргументів;
Решта параметрів (безіменні або мають ім’я, що не відповідає жодному формальному параметру) зіставляються з формальними параметрами по позиціях.
Наприклад:
PS С:\> subtract -from 10 2 8 PS С:\> subtract -count 2 10 8 По умолчанию функции PowerShell, как и другие команды оболочки, ведут себя полиморфным образом, т. е. могут принимать аргументы разных типов. Например, определим функцию add, складывающую два своих аргумента: PS С:\> function add ($х, $у) {$х + $у} Выполним эту функцию с аргументами-числами и аргументами-строками: PS С:\> add 2 3 5 PS С:\> add "2" "3" 23 В первом случае функция add возвращает число 5, а во втором — строку ”23”: PS С:\> (add 2 3).getType().fullName System.Int32 PS C:\> (add "2" "3").getType().fullName System.String При вызове функции может быть указано большее количество фактических аргументов, чем было задано формальных параметров. При этом ’’лишние” аргументы будут помещены В массив $args. Для иллюстрации рассмотрим функцию ShowArgs с двумя формальными параметрами: PS С:\> function ShowArgs ($х,$у) { » "Первый аргумент: $х" >> "Второй аргумент: $у" >> "Остальные аргументы: $args"} » Вызовем эту функцию с одним аргументом: PS С:\> ShowArgs 1 Первый аргумент: 1 Второй аргумент: Остальные аргументы: В этом случае единственный аргумент сопоставляется с параметром $х, значение параметра $у становится равным $nuii, а массив $args не содержит элементов ($args. length=0). Запустим теперь функцию ShowArgs с двумя аргументами: PS С:\> ShowArgs 1 2 Первый аргумент: 1 Второй аргумент: 2 Остальные аргументы: Как видим, в данном случае параметры $х и $у получают значения 1 и 2, а массив $args остается пустым. Наконец, запустим функцию ShowArgs с тремя и четырьмя аргументами: PS С:\> ShowArgs 123 Первый аргумент: 1 Второй аргумент: 2 Остальные аргументы: 3 PS С:\> ShowArgs 1234 Первый аргумент: 1 Второй аргумент: 2 Остальные аргументы: 3 4 Дополнительные аргументы действительно сохраняются в массиве $args.
При оголошенні функції можна явно вказати тип формальних параметрів. Наприклад, давайте визначимо функцію int add, яка додасть два цілих аргументи:
PS С:\> function int_add ([int]$x, [int]$y) {$x + $y} Как и в предыдущем случае, вызовем данную функцию с аргументами-числами и с аргументами-строками: PS С:\> int_add 2 3 5 PS С:\> int_add ”2" "3” 5 Как видим, результат получается один и тот же, символьные аргументы автоматически преобразовались к целочисленному типу. Если преобразование выполнить не удается, то возникнет ошибка: PS С:\> int_add "2а" "3" int_add : Не удается обработать преобразование аргументов для параметра "х". Не удается преобразовать значение "2а" в тип "System.Int32". Ошибка: "Входная строка имела неверный формат." строка:1 знак:9 + int_add "2а" "3" + Categoryinfo : InvalidData: (:) [int_add], ParameterBindingArgumentTransformationException + FullyQualifiedErrorld : ParameterArgumentTransformationError,int_add
Оголошуючи формальні параметри, можна вказати значення, які ці параметри прийматимуть за замовчуванням (якщо ви явно не вкажете відповідний фактичний аргумент).
Например, определим функцию add с двумя формальными параметрами $х и $у, которые по умолчанию инициализируются числами 2 и 3: PS С:\> function add ($х =2, $у = 3) {$х + $у} Если запустить эту функцию без аргументов, то оба параметра инициализируются значениями по умолчанию и функция возвращает число 5: PS С:\> add 5 Если запустить функцию add с одним аргументом, то указанное значение присвоится параметру $х, а параметр $у вновь инициализируется значением по умолчанию ($у=з): PS С:\> add 5 8 При указании двух параметров функция add вернет их сумму: PS С:\> add б 6 12
Перед типом параметра і його назвою можна вказати додатковий набір специфікацій в квадратних дужках у форматі:
parameter(ключ = значение [, . . . ] )
Таким чином, можна, наприклад, вказати, що параметр обов’язковий, визначити його короткий псевдонім і вказати опис цього параметра. У табл. 9.1 показує деякі з цих ключів.
Наприклад, давайте створимо функцію Print-Message, яка буде друкувати рядок, переданий йому як аргумент кілька разів. Параметр для тексту відображеного повідомлення буде називатися -message, кількість повторень буде пропущено через параметр -repeat.
function Print-Message ( [parameter(Mandatory=$true, HelpMessage=’3To очень важный параметр!’)] [string]Smessage, [int]$repeat = 1 ) { for ($i =1; $i -le $repeat; $i++) { Write-Host($message) } }
Тут при визначенні функції ми вказали, що параметр символу $message обов’язковий (Обов’язковий ключ зі значенням $true), і встановили його короткий опис (ключ He1pMessage). Цілочисельний параметр $repeat можна не вказувати при виклику функції, за замовчуванням його значення дорівнює одиниці. Якщо запустити Print-Message без параметрів, оболонка запропонує вказати значення необхідного параметра -message:
PS С:\Users\andrv> Print-Message Командлет Print-Message в конвейере команд в позиции 1 Укажите значения для следующих параметров: (Для получения справки введите "!?’’) message: Если вместо значения -message ввести символы ! ?, tq будет отображено описание этого параметра: PS С:\Users\andrv> Print-Message Командлет Print-Message в конвейере команд в позиции 1 Укажите значения для следующих параметров: (Для получения справки введите "!?”) message: !? Это очень важный параьЛётр! message:
Також за допомогою додаткових атрибутів можна встановити правила перевірки (валідації) значень параметрів. Деякі з цих атрибутів наведені в табл. 9.2.
Атрибути перевірки дуже корисні при написанні функцій і скриптів, вони дозволяють не писати повторюваний код шаблону для перевірки вхідних документів. Наприклад, щоб обмежити кількість повідомлень, які відображаються у функції Print-Message, до опису параметра можна додати атрибут -repeat:
ValidateRange()I function Print-Message ( [parameter(Mandatory=$true, HelpMessage='Это очень важный параметр!’)][string]$message, [ValidateRange(1, 3)][int]$repeat = 1 ) { for ($i = 1; $i -le $repeat; $i++) { Write-Host($message) } } Теперь при попытке передать в параметр -repeat число, большее трех, возникнет ошибка: PS С:\Users\andrv> Print-Message -message 'Привет всем!' -repeat 5 Print-Message : Не удается проверить аргумент для параметра "repeat". Аргумент 5 больше максимально допустимого значения 3. Укажите аргумент, значение которого меньше или равно 3, и повторите команду, строка:1 знак:42 + printmsg -message ’Привет всем! ' -repeat 5 + -ь Categoryinfo : InvalidData: (:) [printmsg], ParameterBindingValidationException + FullyQualifiedErrorld : ParameterArgumentValidationError,printmsg
Щоб отримати додаткові відомості про атрибути параметрів, перегляньте розділ про функції advanced_parameters довідці PowerShell.
До теперішнього часу ми розглянули фактичні параметри двох типів функцій: іменованих (ім’я формального параметра і значення, яке повинен приймати цей параметр) і позиційних (вказується тільки значення аргументу; відповідний формальний параметр визначається положенням цього аргументу в командному рядку).
Нагадаємо, що командлети PowerShell підтримують аргументи третього типу, що представляють собою перемикаються параметри, які задаються тільки власним ім’ям. Таким параметром є, наприклад, командлет -Recurse recurse у командлеті GetChi1dIteme. Якщо цей перемикач вказаний, Get-Chi1dItem впливає не тільки на поточний каталог, але і на всі його підкаталоги.
Ви також можете використовувати аналогічні параметри перемикача у функціях, які повинні мати тип SwitchParameter, який має псевдонім [switchj . Значення перемикача можуть бути тільки $true або $false, тому ініціалізувати такий формальний параметр не потрібно.
Наприклад, створимо функцію Murips з одним параметром перемикача, який визначає поведінку функції:
PS С:\> function MyFunc ([switch] $recurse) { » if ($recurse) { » "Рекурсивный вариант функции" » } » else { "Обычный вариант функции" » } » } » Запустив функцию MyFunc без параметра, мы получим сообщение, что она работает в обычном режиме: PS С:\> MyFunc Обычный вариант функции Если указан параметр -recurse, ТО функция MyFunc будет работать в рекурсивном режиме: PS С:\> MyFunc -recurse Рекурсивный вариант функции
Всі опису параметрів, які ми раніше писали в круглих дужках після імені функції, можна помістити всередину коду самої функції. Для цього першим виконуваним оператором в блоці коду функції повинен бути оператор Param() і перерахувати всередині нього всі формальні параметри функції із зазначенням типів, додаткових атрибутів і значень за замовчуванням (формат такий же, як ми використовували раніше).
Наприклад, розглянута раніше функція Print-Message з використанням оператора Param ( ) буде записана наступним чином:
function Print-Message () { param ( [parameter(Mandatоry=$true, HelpMessage=’Это очень важный параметр!')][string]$message, [ValidateRange(1, 3)][int]$repeat = 1 for ($i = 1; $i -le $repeat; $i++) { Write-Host($message) } }
PowerShell підтримує спеціальний спосіб передачі значень до аргументів командлета або функції за допомогою попередньо стадійованої змінної. Такий прийом називається змінним розбризкуванням.
Перший варіант розлітки дозволяє задавати значення позиційних параметрів за допомогою змінної. Наприклад, створимо функцію Print-Args, яка відображає значення трьох її аргументів:
PS С: \Users\andrv> function Print-Args (param ($x, $y, $z) "x=$x, y=$yf z=$z" } Выполним Print-Args, передав в качестве аргументов три числа: PS С:\Users\andrv> Print-Args 123 х=1, у=2, z=3 Создадим теперь массив $а с теми же числами: PS С:\Users\andrv> $а = 1, 2, 3 Передадим переменную $а В функцию Print-Args: PS С:\Users\andrv> Print-Args $а х=1 2 3, у=, z=
Як бачимо, всередині функції Print-Args параметру $x присвоєні всі три елементи масиву $a. Тепер розіб’ємо змінну $a, вказавши ім’я змінної замість символу $ при виклику функції Print-Agrs:
Выполним теперь сплаттинг переменной $а, указав при вызове функции Print-Agrs перед именем переменной вместо символа $ символ @: PS С:\Users\andrv> Print-Args @а х=1, у=2, z=3 В этом случае элементы массива $а соответствуют позиционным параметрам функции: $х = $а[0], $у = $а[1], $z = $а[2]. Второй вариант сплаттинга связан с передачей значений именованным аргументам функции с помощью хэш-таблицы, ключи в которой совпадают с именами аргументов. Определим для нашего примера хэш-таблицу $ь: PS С:\Users\andrv> $b = @{х=4; у=5; z=6} Вызовем функцию Print-Args с результатом сплаттинга переменной $ь: PS С:\Users\andrv> Print-Args @b х=4, у=5, z=6 Как видим, значения их хэш-таблицы $ь попали в соответствующие параметры функции: $х = $Ь[ ’х’ ], $у = $Ь[ 'у' ], $Z = $b[ 'z' ].
У традиційних випадках програмування функція зазвичай повертає одне значення певного типу. Це не так у PowerShell, де результати всіх виразів або конвеєрів, обчислених всередині функції, спрямовуються до вихідного потоку. Розглянемо, наприклад, функцію MuEips, в якій обчислюються три числових виразу:
В традиционных языках программирования функция обычно возвращает единственное значение определенного типа. В оболочке PowerShell дело обстоит иначе — здесь результаты всех выражений или конвейеров, вычисляемые внутри функции, направляются в выходной поток. Рассмотрим, например, функцию MyFunc, в которой вычисляются три числовых выражения: PS р:\> function MyFunc {1+2; 3*3; 12/4} Как видим, в этой функции явно не возвращается ни одно значение. Запустим ФУНКЦИЮ MyFunc: PS С:\> MyFunc 3 9 3 На экран выводятся три строки с результатами вычислений. Теперь запустим данную функцию и сохраним результат ее работы в переменной $resuit: PS С:\> $result = MyFunc Проверим тип переменной $ result: PS С:\> $result.getType().fullName System.Object[] Переменная $ result является массивом объектов. Найдем длину этого массива и значения его элементов: PS С:\> $result.Length 3 PS С:\> $result[0] 3 PS C:\> $result[l] 9 PS C:\> $result[2] 3
Отже, масив $result містить всі значення, які потрапили в стандартний потік виведення і відображалися на екрані в процесі роботи функції MuEips. Цей факт необхідно враховувати при написанні і налагодженні функцій. Наприклад, визначимо функцію Murips наступного виду:
PS С:\> function MyFunc { » $name = Read-Host "Введите свое имя" » "Здравствуйте, $name!" » $name » } »
Ця функція запитує ім’я користувача (введення з клавіатури здійснюється у змінній $path за допомогою командлета Read-Host), відображає привітання для цього користувача та друкує значення змінної $path у вихідний потік. Запустимо функцію MuEips:
PS С:\> MyFunc Введите свое имя: Андрей Здравствуйте, Андрей! Андрей Проверим теперь, какие данные возвращает функция: PS С:\> $result = MyFunc Введите свое имя: Андрей PS С:\> $result.length 2 PS С:\> $result Здравствуйте, Андрей! Андрей
Так, крім значення змінної $path, у вихідний потік також була включена рядок привітання. Однак, якщо ви використовуєте командлет Write-Host для відображення рядка символів замість звичайного рядка в подвійних лапках, рядок не буде додано до вихідного потоку:
PS С:\> function MyFunc { » $naxne — Read-Host "Введите свое имя" >> Write-Host "Здравствуйте, $naxne!" » $name » } » PS C:\> $resuit = MyFunc Введите свое имя: Андрей Здравствуйте, Андрей! PS С:\> $result.length 6 PS С:\> $result Андрей
Командлет Write-Host друкує рядок безпосередньо на екрані, а не на вихідний потік, тому в цьому випадку функція Mugyps повертає один рядок, значення змінної $path. PowerShell має інструкцію Return, яка негайно виходить з функції (подібно до інструкції Break, описаної в розділі 8 для виходу з циклу). Наприклад:
PS С:\> function MyFunc { » "Эта строка выводится на экран" » return » "Эта строка никогда не будет напечатана" » } » PS С:\> MyFunc Эта строка выводится на экран PS С:\> С помощью данной инструкции можно ’’возвратить" значение из функции, указав нужный объект после слова return. Например, return 10*3 ИЛИ return "Возвращаемая строка".
Вся ідеологія PowerShell побудована на використанні командних конвеєрів, і функції не виняток: їх можна використовувати і всередині конвеєрів. При цьому змінна $input використовується для прийому вхідного потоку об’єктів, переданих від іншої команди всередині функції. Ця змінна буде містити набір вхідних об’єктів.
Давайте розглянемо приклад:
PS С:\> function sum { » $n=0 » foreach ($i in $input) { $n+=$I } » $n » } » PS C:\>
Тут ми визначили функцію суми, яка буде підсумовувати елементи колекції, що надійшли до неї по конвеєру. Результат підсумовування поміщається у вихідний потік як значення змінної $p. Передавши масив чисел функції через конвеєр, отримаємо на виході їх суму:
PS С:\> 1..10 | sum 55
Ви можете перебирати елементи вхідного потоку не тільки за допомогою циклу Forach, але і викликаючи метод MoveNext ( ), звертаючись при цьому до поточного елемента можна скористатися властивістю Current вхідного потоку. Функцію підсумовування елементів вхідного потоку можна переписати наступним чином:
PS С:\> function sum2 { » $n=0 » while ($input.moveNext ()) { >> $n+=$input.current » } » $n » } » Запустим функцию sum2 и убедимся, что она выдает тот же результат, что и функция sum: PS С:\> 1..10 | sum2 55
Таким чином, написати функцію для роботи всередині конвеєра нескладно (досить знати про присвоєння змінної $input), але при отриманні даних від попередньої команди функція ставить конвеєр на паузу і запускається тільки один раз, коли формується вся колекція вхідних елементів.
Функції, з якими ми працювали в попередньому розділі, не повністю підтримували механізм конвеєризації, на відміну від скомпільованих командлетів, які обробляють вхідний елемент конвеєра, не чекаючи генерації наступних елементів. Крім того, командлети мають вбудовану довідку та підтримують загальні параметри. Подібну поведінку можна реалізувати і для функцій PowerShell.
Під час розробки скомпільованих командлетів PowerShell можна вказати три типи дій:
Виконується до обробки першого вхідного елемента.
Виконується для кожного об’єкта у вхідному потоці.
Виконується після того, як останній елемент, який надійшов по трубопроводу, був оброблений.
PowerShell надає можливість реалізувати таку поведінку для користувацьких функцій, які мають три розділи: BEGIN, PROCESS і END. У цих функціях можна ініціалізувати деякий стан перед початком роботи з елементами конвеєра, обробити кожен вхідний об’єкт (не чекаючи генерації наступних елементів) і виконати певні фінішні дії після обробки останнього елемента конвеєра. Загальний синтаксис таких функцій наступний:
function имя_функции ( параметры ) { BEGIN { блок_кода_инициализация } PROCESS { блок_кода_обработка_элемента } END { блок_кода_завершение } }
Ключове слово BEGIN визначає розділ, з якого будуть виконуватися команди перед обробкою першого об’єкта конвеєра. Команди і вирази з розділу PROCESS будуть виконуватися при кожному надходженні нового об’єкта по конвеєру (доступ до поточного пункту в цьому розділі здійснюється через змінну $_). Розділ END містить код, який буде виконаний після обробки останнього об’єкта в конвеєрі. Давайте розглянемо приклад.
Визначимо функцію MyCmd1et з усіма трьома розділами:
PS С:\> function MyCmdiet ($а) { » BEGIN { » $n = 0; "Инициализация: n=$n, а=$а"} » PROCESS { » $n++ » "Обработка конвейера: n=$n, а=$а, текущий обгьект = $_" } » END {"Завершение: п=$п, а=$а"} » }
У кожному з розділів виводиться інформація про значення двох змінних: формальний параметр $a відповідає аргументу, переданому функції, змінна $p визначається в розділі ініціалізації і послідовно збільшується в розділі обробки. Крім того, на ділянці обробки відображається вартість поточного об’єкта, отриманого по трубопроводу (змінна $_). Запустивши цю функцію з аргументом (цифра 4), ми передамо їй по конвеєру числа від 5 до 8:
PS С:\> 5..8 | MyCmdiet 4 Инициализация: п=0, а=4 Обработка конвейера: п=1, а=4, текущий объект = 5 Обработка конвейера: п=2, а=4, текущий объект = 6 Обработка конвейера: п=3, а=4, текущий объект = 7 Обработка конвейера: п=4, а=4, текущий объект = 8 Завершение?: п=4, а=4
Як бачите, аргумент функції (номер 4) і змінна $p, створені в розділі ініціалізації, доступні у всіх трьох розділах. Тепер давайте запустимо функцію MyCmdlet без конвеєра:
PS С:\> MyCmdiet 4 Инициализация: п=0, а=4 Обработка конвейера: п=1, а=4, текущий объект = Завершение: п=1, а=4
З цього робимо висновок, що команди з розділу PROCESS виконуються один раз навіть при відсутності конвеєра.
Нагадаємо, що командлети в PowerShell підтримують ряд загальних параметрів (-Verbose, -Debug, -WhatIf і так далі). Ці параметри також можуть бути оброблені всередині так званих розширених функцій, які всередині свого тіла перед оператором Param() містять деякі атрибути (метадані), що впливають на поведінку функції.
Щоб увімкнути підтримку загальних параметрів функції, потрібно додати до функції атрибут [Cmd1etBinding ( )), щоб функція працювала як командлет. Давайте розглянемо простий приклад того, як цей атрибут впливає на поведінку функції. Почнемо з функції Sum-TwoArgs, яка підсумовує значення двох її аргументів:
PS С:\Users\andrv> function Sum-TwoArgs { » param ($a, $b) » $a + $b » } Проверим синтаксис этой функции с помощью параметра -syntax команды GetCommand: PS С:\Users\andrv> Get-Command Sum-TwoArgs -Syntax Sum-TwoArgs [ [—a] <Object>] [[—b] <Object>] Как видим, Sum-TwoArgs не поддерживает общие параметры командлетов. Вызовем нашу функцию с тремя параметрами: PS С:\Users\andrv> Sum-TwoArgs 123 3 В этом случае ошибки не произошло, была вычислена сумма первых двух аргументов, а третий аргумент был помещен в переменную Sargs. Добавим теперь к функции Sum-TwoArgs перед оператором Paramo атрибут [CmdletBinding()]: PS С:\Users\andrv> function Sum-TwoArgs { » [CmdietBindingO] 190__________________________________ Часть II. PowerShell как язык программирования » param ($а, $Ь) » $а + $Ь » } Вновь проверим синтаксис: PS С:\Users\andrv> Get-Command Sum-TwoArgs -Syntax Sum-TwoArgs [[-a] <Object>] [[—b] <Object>] [<CommonParameters>] Как видим, теперь функция Sum-TwoArgs поддерживает общие параметры. Вновь вызовем функцию с тремя аргументами: PS С:\Users\andrv> Sum-TwoArgs 123 Sum-TwoArgs : Не удается найти позиционный параметр, принимающий аргумент ”3”. строка:1 знак:1 + Sum-TwoArgs 123 + Categoryinfo : InvalidArgument: (:) [Sum-TwoArgs], ParameterBindingException + FullyQualifiedErrorld : PositionalParameterNotFound,Sum-TwoArgs
Тепер отримуємо повідомлення про помилку, так як при виклику командлетів кількість переданих аргументів не повинно перевищувати кількість формальних параметрів. Отже, тепер наша функція поводиться як командлет.
У функції, для якої вказано атрибут [Cmd1etBinding( )], можна використовувати команди Write-* для запису повідомлень у додаткові потоки, наприклад Verbose або Debug. Наприклад, роздрукуємо докладне повідомлення про проведену операцію в нитку Verbose:
PS С:\Users\andrv> function Sum-TwoArgs { » [ CmdletBinding () ] » param ( » $a, $b » ) » Write-Verbose "Функция вычисляет сумму двух аргументов: а=$а и Ь=$Ь" » $а + $Ь » } При обычном запуске функции Sum-TwoArgs сообщения на экране мы не увидим: PS С:\Users\andrv> Sum-TwoArgs 1 2 3 Выполним теперь функцию с общим параметром -verbose. В этом случае содержимое канала verbose будет отображено на экране. PS С:\Users\andrv> Sum-TwoArgs 1 2 -Verbose ПОДРОБНО: Функция вычисляет сумму двух аргументов: а=1 и Ь=2 3
До сих пір ми працювали в інтерактивному режимі в PowerShell, набирали команди і отримували результат їх виконання. Якщо завтра нам потрібно буде виконати ті ж команди, що і сьогодні, нам доведеться знову їх вводити. Тому часто використовувані послідовності команд краще зберігати в зовнішніх скриптах, які виконуються в пакетному режимі, тобто без участі людини.
Сценарії PowerShell – це текстові файли з розширенням PSL, які містять код (команди, оператори та інші конструкції) мовою PowerShell. Писати скрипти PowerShell можна покроково, безпосередньо в самій оболонці, а потім перенести готовий код в зовнішній текстовий файл. Такий підхід значно спрощує вивчення мови і налагодження скриптів, дозволяючи побачити результат виконання окремих частин скрипта з першого погляду.
Існує багато способів створення файлу сценарію PowerShell.
Про програму Використовуйте зовнішній текстовий редактор (наприклад, стандартний блокнот Windows або автономний код Visual Studio Code) вручну введіть потрібні команди та збережіть файл із розширенням PSL.
Запустіть потрібні команди в PowerShell, потім скопіюйте їх з консолі в буфер обміну Windows і вставте в текстовий файл, відкритий у зовнішньому текстовому редакторі. Отриманий файл зберігається з розширенням psl.
Якщо ви працюєте в PowerShell, використовуйте командлет StartTranscript, щоб увімкнути режим журналювання команд, описаний у розділі 4. В результаті буде створено зовнішній файл з усіма командами, що виконуються в сеансі. З цього файлу ви можете скопіювати потрібні команди в інший текстовий файл і зберегти його з розширенням .psl.
Перебуваючи в PowerShell, відформатуйте команди PowerShell як рядки (звичайні або рядки here) і перенаправте ці рядки, використовуючи > символи, і >> ці рядки до зовнішнього файлу з розширенням .ps.
Скористаємося останнім із запропонованих варіантів і створимо простий скрипт test.psl в директорії скрипта, який буде складатися з одного рядка:
PS С:\Users\andrv\script> Set-ExecutionPolicy -Scope Process RemoteSigned Итак, мы разрешили выполнение сценариев. Вновь попробуем запустить наш скрипт, указав его имя: PS С:\Users\andrv\script> test.psi test.psi : Имя "test.psi" не распознано как имя командлета, функции, файла сценария или выполняемой программы. Проверьте правильность написания имени, а также наличие и правильность пути, после чего повторите попытку. строка:1 знак:1 + test.psi + ---- + Categoryinfo : ObjectNotFound: (test.psi:String) [], CommandNotFoundException + FullyQualifiedErrorld : CommandNotFoundException Гпава 9. Функции, фильтры, сценарии и модули___________________________________ 193 Suggestion [3,General]: Команда test.psi не найдена, однако существует в текущем расположении. По умолчанию оболочка Windows PowerShell не загружает команды из текущего расположения. Если вы уверены в надежности команды, введите ".\test.psi”. Для получения дополнительных сведений вызовите справку с помощью команды "get-help about_Cornmand_Precedence".
Знову помилка … Справа в тому, що при запуску скриптів PowerShell шлях до файлу коду потрібно завжди вказувати явно, навіть якщо скрипт знаходиться в поточному каталозі, адже це запобігає можливе несанкціоноване виконання іншої виконуваної програми з таким же ім’ям, що знаходиться, наприклад, в системному каталозі. Тому запустимо скрипт, явно вказавши шлях до нього (точка в шляху до Fight відповідає поточному каталогу):
PS С:\Users\andrv\script> .\test.psl Эта строка печатается из сценария PowerShell Итак, в этом случае сценарий выполняется. Можно даже не указывать расширение psi: PS C:\Script> .\test Эта строка печатается из сценария PowerShell Естественно, путь можно было задать полностью: PS C:\Script> C:\Users\andrv\script\test.psl Эта строка печатается из сценария PowerShell PS C:\Script> C:\Users\andrv\script\test Эта строка печатается из сценария PowerShell Если в пути к сценарию содержатся пробелы, то имя нужно заключить в кавычки, и поставить в начале знак амперсанда (&), означающий в PowerShell оператор запуска. Например: PS C:\Script> &'С:\Мои cxpnnTbi\script.psi'
Сценарії PowerShell можна запускати безпосередньо з командного рядка cmd.exe або за допомогою параметра “Виконати” в меню “Пуск”. Для цього ви вказуєте повний шлях до цього скрипту як значення параметра -Fi1e в інструменті powershell.exe. При цьому повний шлях до powershell.exe і розширення exe можна опустити, наприклад:
С:\> powershell -File C:\Users\andrv\script\test.psl
Нагадаємо, що файли команд інтерпретатора cmd.exe, а також скрипти WSH в VBScript або JScript розглядаються Windows як виконувані, їх можна запустити з провідника, просто натиснувши на іконки цих скриптів. Цей метод не працює зі сценаріями PowerShell — якщо двічі клацнути піктограму сценарію PowerShell, він не запуститься, але відкриється для редагування в Блокноті (з точки зору безпеки це правильний підхід, щоб запобігти випадковому запуску сценарію).
По суті, скрипт PowerShell – це функція, яка знаходиться не в оперативній пам’яті, а на зовнішніх носіях. Тому синтаксичний аналіз і обробка аргументів, переданих в скрипті, виконується приблизно так само, як і у функціях.
Аргументи задаються після імені сценарію та розділяються пробілами. Змінна $args всередині скрипта містить масив, елементами якого є аргументи функції, задані при її запуску. Наприклад, напишемо скрипт SumArgs.ps1, який повідомить кількість параметрів, за допомогою яких він запускається, і їх суму. Створимо файл вихідного коду наступним чином: текст скрипту буде відформатовано як рядок типу here-string (аналогічні рядки були описані в розділі 7) і перенаправимо цей рядок у файл SumArgs.psl:
PS C:\Script> 0-' » "Количество аргументов: $($args.count)" » $n=0 » for($i=0; $i -It $args.count; $i++) { $n+=$args[$i] } » "Сумма аргументов: $n" » > SumArgs.psl » Запустим теперь сценарий SumArgs.psl с несколькими числовыми параметрами: PS C:\Script> .\SumArgs 123 Количество аргументов: 3 Сумма аргументов: 6
Як бачите, масив $args в скриптах має той же сенс і обробляється так само, як і у функціях.
У скриптах ви можете визначити формальні параметри, які будуть замінені під час виконання фактичними аргументами, переданими скрипту. Нагадаємо, що в функціях ми могли б перераховувати формальні параметри або в дужках після імені, тобто поза тілом функції, або всередині функції за допомогою оператора Param ().
У скриптах параметри можуть бути описані тільки за допомогою Param(), оскільки тут весь вміст файлу є тілом скрипта. Ця інструкція повинна бути першою виконуваною командою у файлі, якій передуватимуть лише порожні рядки, коментарі та додаткові атрибути у випадку розширених скриптів.
Наприклад, напишемо скрипт add.psl з двома формальними параметрами, який виведе суму його аргументів. Для створення скрипта ми знову будемо використовувати рядок типу here-string, яку перенаправимо в файл:
PS C:\Script> 0' » param ($х=2, $у=3) » $х+$у » '@ > add.psi » Запустим полученный сценарий с аргументами и без них: PS C:\Script> .\add 10 20 30 PS C:\Script> .\add 5 Все работает правильно: если аргументы не указаны, то внутри сценария используются значения по умолчанию
У звичайному режимі вихід зі скрипта, так само як і з функції, відбувається після виконання в ньому останнього оператора. Нагадаємо, що у функції можна було використовувати оператор Return для примусового відключення роботи. Аналогом цього оператора для скриптів є оператор Exit, який дозволяє вийти зі скрипта і повернути певний код повернення при необхідності. Код повернення можна проаналізувати в зовнішніх програмах (таких як пакетні файли або сценарії WSH), які запускають сценарій PowerShell.
Давайте розглянемо приклад. Давайте створимо пакетний файл Call PS.bat в якому буде викликатися скрипт PowerShell, заданий рядком ” ‘ PoSH-script is working’; вихід 10″, і відображає значення змінної середовища ERRORLEVEL, яке дорівнює коду повернення останнього запущеного процесу, як показано в списку 9.1
Лістинг коду 9.1. Визначення коду виходу сценарію PowerSheIl (файл виклику PS.bat)
@echo off echo Запускаем сценарий PowerShell... powershell "'PoSH-script is working'; exit 10" echo Код возврата процесса PowerShell: %ERRORLEVEL% Запустив файл Call_PS.bat в оболочке cmd.exe, мы получим следующий результат: С:\Script>call_ps.bat Запускаем сценарий PowerShell... PoSH-script is working Код возврата процесса PowerShell: 10
Список всіх функцій, доступних у PowerShell, зберігається в віртуальному приводі Function: і ви можете переглянути його вміст за допомогою команди Get-Chi1dItem (псевдонім rer):
PS С:\Users\andrv> dir function: CommandType Name Function Function A: B: Function С: Function Function Function cd. . cd\ Clear-Host
Якщо ми вручну ввели функцію у вікно PowerShell (або скопіювали її з буфера обміну), то вона буде доступна тільки в поточному сеансі оболонки. В іншому вікні PowerShell ми не зможемо скористатися цією функцією.
Функції, описані у зовнішньому файлі сценарію, будуть доступні лише в цьому файлі. Існує два способи гарантувати, що заявлені в скрипті функції залишаються в пам’яті після виконання скрипта.
Якщо запустити сценарій PowerShell у так званому режимі точкового пошуку, де шляху до сценарію передує крапка та пробіл, його вміст буде виконуватися так, ніби його вміст буде введено безпосередньо в командному рядку. Іншими словами, сценарій виконується в області вікна командного рядка, тому всі функції та змінні, присутні в сценарії, набувають глобального обсягу і будуть доступні в оболонці після завершення сценарію.
Щоб протестувати цей режим, давайте додамо нову функцію Loca1Func до сценарію test.psl з областю за замовчуванням:
PS С:\Users\andrv> "function LocalFuncO { 'Это функция LocalFunc' }" » test.psi Выполним сценарий test.psl в режиме dot-sourcing и убедимся в доступности функции LocalFunc В оболочке: PS С:\Users\andrv> . .\test.psl PS С:\Users\andrv> LocalFunc Это функция LocalFunc Подобным образом можно применить изменения в своем профиле, сделанные во время текущего сеанса работы, без перезагрузки оболочки. Путь к профилю хранится в переменной $ profile, поэтому для этого достаточно выполнить следующую команду: PS С:\Users\andrv> . $PROFILE В режиме dot-sourcing можно запускать не только сценарии, но и функции. Например: PS С:\Users\andrv> function set-var ($х) {$х = $х} PS С:\Users\andrv> . set-var 5 PS С:\Users\andrv> $х 5 Если некоторые переменные и функции из сценария должны остаться локальными даже в режиме dot-sourcing, то перед их именами нужно указать спецификаторы local: ИЛИ script:.
Великою чеснотою програмістів і адміністраторів є небажання виконувати зайву роботу. Немає необхідності винаходити велосипед знову і знову – якщо хтось вже повністю або частково вирішив цікаву для нас проблему, написав для цього код, то простіше і правильніше буде скористатися цим рішенням, а не писати код заново.
Сучасні пошукові системи в інтернеті значно полегшують життя розробникам, ми можемо швидко знайти відповідні приклади на різних мовах програмування на спеціальних сайтах. Для сценаріїв PowerShell існує централізоване сховище, підтримуване Microsoft, галерея PowerShell (https://www.powershellgallery.com/), яка містить кілька тисяч мовних пакетів PowerShell, розроблених Microsoft та іншими членами спільноти PowerShell. Також тисячі можна знайти на GitHub (офіційний репозиторій команд PowerShell знаходиться за адресою https://github.com/powershell).
Як тільки скрипт знайдений, потрібно застосувати його в своїх цілях, і саме тут виникає проблема простого і зручного повторного використання коду. Для цього в PowerShell прийнято формувати код в модулі, які містять елементи модуля: командлети, функції, змінні, псевдоніми, які при необхідності можна завантажити в оболонку і використовувати з командного рядка або ваших скриптів.
Модулі в PowerShell допомагають виконати два основних завдання.
Додайте нову функціональність до командної оболонки. У попередніх розділах ми розглянули процедуру завантаження ваших функцій в оболонку в режимі dot-sourcing. Модулі дозволяють зробити це більш зручним і надійним способом.
Повторне використання коду. Модулі в PowerShell, як і в інших мовах програмування, дозволяють створювати і поширювати бібліотеки, з яких підключаються функції і використовуються в їх скриптах.
PowerShell використовує кілька типів модулів, включаючи двійкові, які містять скомпільовані командлети, і модулі Script, які є сценаріями PowerShell у файлах з розширенням .psml (нагадаємо, що звичайні сценарії PowerShell мають розширення .ps 1).
Якщо модуль знаходиться в підкаталозі одного з каталогів, зазначених у змінній середовища PSModu1ePath, він буде автоматично завантажений в оболонку при першому виклику будь-якої команди з цього модуля:
PS С: \Users\andrv> $ENV:PSModuiePath -split С:\Users\andrv\OneDrive\Documents\WindowsPowerShell\Modules С:\Program Files\WindowsPowerShell\Modules С:\WINDOWS\system32\WindowsPowerShell\vl.0\Modules
Таким чином, модулі скриптів дозволяють писати власні функції, які будуть працювати аналогічно вбудованим командлетам, автоматично завантажуючись в оболонку при кожному запуску PowerShell.
Наприклад запишемо дві функції, Out-Hello і Out-GoodBye, у файл MyModule.psml. Ці функції будуть виводити повідомлення з ім’ям поточного користувача:
PS С:\Users\andrv> 'function Out-Hello() { "Привет, $env: UserName! " }' > MyModule. psml PS C:\Users\andrv> 'function Out-GoodBye() { "Пока, $env:UserName! " }' » MyModule. psml Проверим содержимое файла MyModule.psml: PS C:\Users\andrv> Get-Content . \MyModule.psml function Out-Hello() { "Привет, $env:UserName!" } function Out-GoodBye() { "Пока, $env:UserName!" } В переменную $moduieDir сохраним каталог для хранения пользовательских модулей (первый каталог из переменной окружения PSModuiePath): PS С:\Users\andrv> $moduleDir = ($ENV:PSModuiePath -split ';')[0] Создадим в этом каталоге подкаталог MyModule (имя подкаталога должно совпадать с именем файла с модулем): PS С: \Users\andrv> New-Item -Path $moduleDir/MyModule -ItemType Directory Каталог: C:\Users\andrv\OneDrive\Documents\WindowsPowerShell\Modules Mode LastWriteTime Length Name d---- 11.06.2021 6:06 MyModule Скопируем в созданный подкаталог файл MyModule.psml нашего модуля: PS С:\Users\andrv> Copy-Item -Path .\MyModule.psml -Destination $moduleDir\MyMbdule Теперь наш модуль стал доступным для загрузки. Проверить это можно с помощью командлета Get-Module С параметром -ListAvailable: PS С: \Users\andrv> Get-Module -ListAvailable MyModule | Format-List Name Path : MyModule : C:\Users\andrv\OneDrive\Documents\WindowsPowerShell\ Modules\MyModule\MyModule.psml Description ModuleType Version NestedModules : Script : 0.0 : {} ExportedFunctions : {Out-Hello, Out-GoodBye} ExportedCmdlets : ExportedVariables : ExportedAliases : Как видим, оболочка нашла наш модуль и определила, что из него экспортируются функции Out-Hello И Out-GoodBye. Замечание По умолчанию из модуля экспортируются все его члены (функции, переменные, псевдонимы и т. д.). Это поведение можно изменить, явно перечислив экспортируемые члены с помощью командлета Export-ModuleMember. Загрузим наш модуль С ПОМОЩЬЮ командлета Import-Module. Параметр -Verbose позволяет увидеть, какие фунции импортируются из модуля: PS С: \Users\andrv> Inport-Module MyModule -Verbose ПОДРОБНО: Импорт функции "Out-GoodBye". ПОДРОБНО: Импорт функции "Out-Hello". После импорта модуля MyModule В оболочке станут доступны функции Out-Hello И Out-GoodBye: PS С:\Users\andrv> Out-Hello Привет, andrv! PS C:\Users\andrv> Out-GoodBye Пока, andrv! При следующем запуске PowerShell модуль MyModule будет загружен автоматически, объявленные в нем функции останутся доступными.
За замовчуванням централізованим сховищем модулів і скриптів PowerShell є ресурс галереї PowerShell (https:llwww.powershellgallery.com/), яким керує корпорація Майкрософт. Відомості про цей репозиторій можна отримати за допомогою командлета Get-PSRepository:
PS С:\Users\andrv> Get-PSRepository | Format-List PackageManagementProvider : NuGet Name SourceLocation Trusted Registered Installationpolicy : PSGallery : https://www.powershellgallery.com/api/v2 : False : True : Untrusted Как видим, централизованный репозиторий имеет имя PSGallery. PublishLocation ScriptSourceLocation : https://www.powershellgallery.com/api/v2/package/ : https://www.powershellgallery.com/api/v2/items/ psscript ScriptPublishLocation Provideroptions : https://www.powershellgallery.com/api/v2/package/ : {} Работать с репозиторием можно с помощью команд из модуля PowerShellGet: PS С:\Users\andrv> Get-Command -Module PowerShellGet | Format-Wide -Column 2 Find-Command Find-Module Find-Script Get-InstalledScript Install-Module New-ScriptFilelnfo Publish-Script Save-Module Set-PSRepository Uninstall-Module Unregister-PSRepository Update-ModuleManifest Update-ScriptFileinfo
Пошук модулів виконується за допомогою командлета Find-Module. Якщо виконати цю команду без параметрів, то буде виведено повний список усіх наявних в PowerShell Gallery модулів:
PS С: \Users\andrv> Find-Module -Repository PSGallery | Format-Wide -Column 2 Speculationcontrol PSWindowsUpdate PackageManagement PowerShellGet Carbon Azure.Storage Az.Resources Az.Automation Az.ApiManagement Az.Compute Az.Applicationinsights Az.Aks Az.Sql Az.DataFactory Az.ContainerRegistry Az.EventHub Az.ServiceBus Az.Monitor Az.Operationallnsights NetworkingDsc AzureRM.profile DellBIOSProvider Az.Accounts Compute rManagement Dsc Az.Storage Az.KeyVault Az.Analysisservices xPowerShellExecutionPolicy PSLogging xCertificate Az .Network Az.Batch Az.Cdn Az.DataLakeStore Az .Websites Az.HDInsight Az.Containerinstance Az.DataLakeAnalytics
Якщо ім’я потрібного модуля відоме, слід вказати його як значення параметр -Name. Наприклад:
PS С:\Users\andrv> Find-Module -Repository PSGallery -Name PSLogging | Format-List PowerShellGetFormatversion Name Version Type Description Author CompanyName Copyright PublishedDate InstalledDate UpdatedDate LicenseUri : PSLogging : 2.5.2 : Module : Creates and manages log files for your scripts. : LucaSturlese : 9to5lT : (c) 2015 Luca Sturlese. All rights reserved. : 11/22/2015 10:26:55 AM : http://9to5it.com/powershell-logging-v2-easilycreate-log-files ProjectUri create-log-files IconUri Tags Includes : http://9to5it.com/powershell-logging-v2-easily- : (Logging, LogFiles, PSModule} : (Function, RoleCapability, Command, DscResource... ReleaseNotes : Removed HelpInfoURI from Module Manifest file as was causing an issue with PowerShell 2.0 Dependencies RepositorySourceLocation Repository PackageManagementProvider : (} : https://www.powershellgallery.com/api/v2 : PSGallery : NuGet
Встановлюється модуль із репозиторію за допомогою командлета Install-Module. за модулі встановлюються в каталог C:\Program Files\WindowsPowerShell\ Modules, що вимагає виконання команди Install-Module в оболонці, запущеній від імені адміністратора. Для встановлення модуля у профіль поточного користувача потрібно вказати параметр -scope зі значенням Currentuser і ствердно відповісти на питання про встановлення:
PS С:\Users\andrv> Install-Module -Name PSLogging -Scope Currentuser Untrusted repository You are installing the modules from an untrusted repository. If you trust this repository, change its Installationpolicy value by running the Set-PSRepository cmdlet. Are you sure you want to install the modules from ’PSGallery’? [Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help (default is "N") : у Для проверки загруженного модуля можно посмотреть, какие команды в нем содержатся: PS С:\Users\andrv> Get-Command -Module PSLogging CommandType Name Version Function Function Send-Log Start-Log 2.5.2 2.5.2 204 Часть II. PowerShell как язык программирования Function Function Function Function Stop-Log Write-LogError Write-Loglnfo Write-LogWarning 2.5.2 2.5.2 2.5.2 2.5.2 Обновить модуль (т. e. установить его новую версию) можно с помощью командлета Update-Module, удалить МОДУЛЬ С локальной машины— С ПОМОЩЬЮ UninstallModule.
Функції в PowerShell створюються за допомогою ключового слова функції.
На відміну від інших мов програмування, функція в PowerShell є командою, тому вам потрібно викликати функції як команди — аргументи розділяються пробілом після імені функції.
Найпростіший спосіб передати аргументи функції – це перебрати елементи масиву $args.
Ви можете вказати формальні параметри для функції в PowerShell, вказавши їх у дужках після імені функції (як це робиться в інших мовах програмування) або всередині самої функції за допомогою спеціального оператора Param(). При цьому можна явно вказати типи таких параметрів, встановити для них значення за замовчуванням і інші атрибути для перевірки аргументів, переданих функції при виклику.
Коли викликається функція, її формальні параметри замінюються фактичними аргументами, які ідентифікуються позицією в командному рядку або ім’ям параметра.
Тіло функції може містити розділи ПОЧАТОК, ПРОЦЕС і КІНЕЦЬ. У цьому випадку функції можуть бути правильно використані всередині трубопроводів.
Якщо встановити для функції атрибут Cmd1etBinding ( ), вона буде вести себе як командлет. Такі функції називаються розширеними, вони роблять доступними загальні параметри командлета і додаткові потоки виводу Verbose, Debug, Error.
Кожен вираз, обчислений у функції, поміщає свій результат у вихідний потік.
Щоб керувати функціями, доступними в поточному сеансі PowerShell, використовуйте Функція: віртуальний диск.
Сценарій PowerShell – це функція, яка не знаходиться в оперативній пам’яті, а зберігається в текстовому файлі з розширенням .psl. Визначення, синтаксичний аналіз і обробка аргументів, що передаються в скрипті, виконуються так само, як і у функціях.
Режим виконання скриптів у PowerShell визначається політикою виконання, яку можна змінити за допомогою команди Set-ExecutionP01icy. Рекомендую-
Функції в PowerShell можуть мати різні області застосування. Щоб гарантувати, що функції, оголошені в скрипті, залишаються доступними в оболонці після виконання сценарію, ви можете створити функції в глобальному масштабі або запустити скрипт в режимі dot-sourcing.
За замовчуванням змінна в PowerShell є локальною для сценарію, функції або блоку коду, в якому вона була ініціалізована. Області змінних можуть бути встановлені явно, вказавши визначники перед їх іменами.
Для спрощення повторного використання коду використовуються модулі PowerShell, які містять командлети, функції, змінні та псевдоніми, які за бажанням можна завантажити в оболонку та використовувати їх із командного рядка або сценаріїв.
Microsoft підтримує централізоване сховище модулів і сценаріїв PowerShell, галерею PowerShell.
Дякуємо нашій команді волонтерів за надану інформацію з відкритих джерел.