04.03.2011 Дон Джоунз
Каждому, кто составлял сценарии PowerShell, наверняка приходилось тратить немало времени на их отладку. Ошибки неизбежны, когда нужно добиться, чтобы компьютер выполнил то или иное действие. На первый взгляд в PowerShell немного средств, упрощающих отладку. В этой статье мы рассмотрим несколько основных методов отладки и некоторые приемы, с помощью которых можно избежать ошибок
В PowerShell нет встроенного графического отладчика для построчной проверки сценариев, однако выручают бесплатные и коммерческие инструменты сторонних поставщиков. В таких редакторах, как PowerGUI компании Quest Software (powergui.org), Idera PowerShellPlus (powershellplus.com) и PrimalScript компании SAPIEN Technologies (www.primaltools.com) используют различные методы построчного выполнения сценариев PowerShell, чтобы видеть содержимое переменных и в целом упростить отладку. Однако для успешного применения любого из этих инструментов необходимо овладеть общими навыками отладки.
Прежде чем приступить к отладке, нужно определить объект поиска, иными словами, что считать ошибкой. Существует две отчетливые разновидности ошибок.
Первый тип ошибки: толстые пальцы
Первый тип - простая синтаксическая ошибка. Опечатка. Сбой оператора. Толстые пальцы. Выберите название, которое вам больше нравится. Обнаружить эти ошибки довольно просто, так как PowerShell выдает сообщение, в котором указывается номер строки, содержащей неверный символ. Однако сведения о номере строки мало помогут пользователям Notepad, так как в программе не показаны номера строк. По этой причине рекомендуется заменить Notepad на бесплатную программу PowerGUI или коммерческий редактор сценариев.
Возможности коммерческих редакторов не ограничиваются лишь нумерацией строк, а некоторые их функции помогут предотвратить опечатки. Главная из них - выделение синтаксиса, то есть представление исходного текста сценария различными цветами. Ключевая особенность цветового выделения заключается в том, что элементы окрашиваются в нужный цвет только в случае правильного написания. Поэтому пользователям редакторов с функцией выделения синтаксиса полезно изучить цветовые обозначения команд, переменных, строк литералов и т. д. Если они не окрашиваются нужным цветом во время ввода, значит, произошла ошибка. Остановитесь и выясните причину ошибки.
Если что-то пропущено, от PowerShell поступают сигналы. Обратите внимание на сообщения об ошибках. Очень часто администраторам трудно устранить неполадки просто потому, что они не читают этих сообщений. При виде красного текста на экране они впадают в панику и начинают пробовать разные способы. Но в сообщении указано, в какой строке исходного текста содержится ошибка. Поэтому сосредоточьтесь, внимательно прочитайте сообщение, уясните его смысл и постарайтесь найти причину неполадки.
В хорошем редакторе сценариев можно получить дополнительную информацию, запустив в PowerShell своего рода «предполетную проверку» сценария. Обычно эту функцию называют динамической проверкой синтаксиса. Часто внимание пользователя незамедлительно привлекается к простым ошибкам, еще до запуска сценария. В некоторых редакторах используется красное подчеркивание (как при проверке правописания в Microsoft Word); в других применяются иные визуальные индикаторы.
Наконец, чтобы избежать неприятностей, соблюдайте некоторые правила. Аккуратно структурируйте исходный текст, чтобы конструкции располагались с отступами, выравнивая фигурные скобки, как в следующем примере:
Function get-что-нибудь { # Исходный текст }
Это лучше, чем следующая аморфная запись:
Function get-что-нибудь {# Исходный текст}
Второй тип ошибки: расхождения желаемого и действительного
В результате ошибок второго типа не удается достичь желаемых результатов. Сценарий выполняется без запинок, но не решает поставленную задачу. PowerShell обычно не выдает сообщений об ошибках такого типа или же сообщения не содержат полезной информации. Возможны всего две причины возникновения ошибок подобного типа.
Логическая ошибка. Иногда программисты допускают простые логические ошибки. Например, составлен сценарий, который должен посчитать от 1 до 10:
For ($i=0; $i -lt 10; $i++) { Write-host $i }
Сценарий выполняется успешно, но отображаются числа от 0 до 9. Результат близок, но не совсем соответствует намерениям программиста. В этом случае полезно остановиться и вспомнить принципы выполнения сценариев. Представьте, как программа PowerShell прочитывает сценарий, отметьте содержимое переменных на каждом шаге и результаты каждого шага. Для приведенного сценария ход рассуждений может быть следующим.
Сначала нужно назначить переменной $i значение 0 (записываем $i=0). 0 меньше 10? Да, поэтому используем Write-Host для отображения значения 0 (записывается результат 0) и увеличиваем значение переменной $i на единицу. На данном этапе $i содержит 1 (записываем $i=1). 1 меньше 10? Да, поэтому отображается значение 1 (записывается результат 0) и переменная $i увеличивается на единицу. Теперь $i содержит 2 (записываем $i=2). Это число меньше 10, поэтому оно выводится на экран (записывается результат 2) и т. д.
Так будет продолжаться, пока значение $i не достигнет 10. В результате сравнения оказывается, что 10 не меньше 10, поэтому PowerShell не отображает это число. Как показано в примере, элементарные логические ошибки становятся очевидными, если уделить время простому анализу алгоритма.
Неверные предположения. Поэтапное воспроизведение алгоритма поможет найти не только элементарные, но и более серьезные логические ошибки, так как запись на бумаге содержит перечень ожидаемых состояний. Предположим, программист мысленно воспроизвел сценарий и записал события, которые, по его мнению, должны произойти. В ходе выполнения сценария происходит нечто другое. Такую ошибку можно назвать «ложными ожиданиями» или «незнанием». Причина проста: значение переменной, свойства или результат метода иные, чем предполагалось. В результате анализа логики сценария был составлен письменный перечень ожидаемых состояний. Нужно лишь составить аналогичный список с помощью PowerShell и посмотреть, какие результаты отличаются от ожидаемых. Обнаружив различия, вы найдете ошибку.
Существует два основных метода формирования в PowerShell списка, соответствующего создаваемому в процессе мысленной проверки алгоритма. Эти методы основаны на использовании команд Write-Debug и Set-PSDebug. Существует и третий способ с использованием интерактивного отладчика в редакторе сценариев. В сущности, этот метод представляет собой комбинацию двух базовых методов, которые будут рассмотрены в данной статье. Полезно освоить базовые приемы, прежде чем воспользоваться более удобным способом интерактивного отладчика в редакторе.
Метод 1: Write-Debug
В первом методе используется команда Write-Debug. По умолчанию вывод этой команды подавляется. Чтобы разрешить вывод, необходимо добавить в начало сценария строку
$DebugPreference = "Continue"
Затем следует ввести инструкции Write-Debug непосредственно после каждой инструкции, в которой изменяется содержимое переменной, например:
$var = get-service Write-Debug "`$var contains $var"
Обратите внимание на небольшую хитрость: вывод команды Write-Debug заключен в двойные кавычки. В результате переменные заменяются их содержимым. Для первой переменной используется обратный апостроф (экранирующий символ в PowerShell), поэтому символ $ экранирован. Это приводит к тому, что первый элемент $var отображается как есть, а имя переменной выводится на экран. Второй элемент $var заменяется его содержимым.
Затем нужно ввести инструкцию Write-Debug в каждый цикл и конструкцию принятия решения. В листинге показано, как применить метод для цикла for и конструкции if. В инструкции Write-Debug во фрагменте A используется тот же прием с двойными кавычками и обратным апострофом, чтобы выяснить содержимое $i при каждом повторении цикла for. В конструкции if используются две функции Write-Debug, в том числе и в конструкции else (фрагмент B). Таким образом удается собрать данные для диагностики независимо от ветвления, несмотря на отсутствие программного кода, который бы исполнялся, когда значение $i не больше 2. Обратите внимание, что для вывода инструкций Write-Debug используется одинарная кавычка, чтобы не заменять переменную $i ее содержимым.
После добавления всех инструкций Write-Debug нужно запустить сценарий и сравнить вывод с записанными ожидаемыми значениями. Отметьте любые различия. Возможно, придется пересмотреть ожидания, но любое различие следует рассматривать как указатель на потенциальную ошибку.
Если сценарий выполняется, как ожидалось, просто замените $DebugPreference в начале сценария на
$DebugPreference = "SilentlyContinue"
и диагностический вывод будет подавлен. Удалять инструкции Write-Debug не обязательно. Оставив их на месте, можно облегчить отладку сценария в будущем.
Метод 2: Set-PSDebug
Второй метод основан на использовании встроенного пошагового отладчика Set-PSDebug для построчного выполнения сценария. В длинных сценариях процедура может показаться утомительной, но в PowerShell 1.0 приходится довольствоваться этим. В PowerShell 2.0 появились контрольные точки, о которых будет рассказано в следующей статье. С их помощью можно задать момент перехода сценария в режим ожидания, не выполняя его построчно.
Для запуска отладчика выполните команду
Set-PsDebug -step
Позднее его можно отключить командой
Set-PsDebug -off
Включенный отладчик действует на все сценарии (а также на команды, введенные в командной строке). Нужно просто запустить сценарий и приступить к отладке. Каждый раз, обнаруживая строку сценария, PowerShell отображает ее и просит подтверждения, чтобы продолжить выполнение. Полезно иметь распечатку с пронумерованными строками, чтобы точно видеть, какое место сценария выполняет PowerShell. Чтобы выполнить строку, нажмите клавишу Enter. В процессе выполнения можно сравнивать ожидаемые результаты с реально полученными.
Не нажимайте клавишу Enter всякий раз, когда сценарий изменяет переменную или готовится обратиться к свойству переменной или объекта. Вместо этого введите S и нажмите Enter. При этом выполнение сценария приостанавливается, и на экране появляется особое приглашение. С его помощью можно:
- обращаться к переменным, чтобы увидеть их содержимое;
- запускать команды, чтобы увидеть их результат;
- просматривать свойства объекта, чтобы увидеть их содержимое.
Различие между реальными и ожидаемыми результатами свидетельствует об ошибке. Выполните команду Exit, чтобы выйти из режима ожидания и возобновить выполнение сценария с того места, где он был остановлен.
Требуется некоторое время, чтобы привыкнуть к пошаговому отладчику. Однако это полезный инструмент для проникновения внутрь выполняемого сценария.
К отладке готов?
Процедура отладки не обязательно сложна при методичном и согласованном подходе. Не расстраивайтесь, получая сообщение об ошибке. Внимательно прочитайте и уясните смысл сообщения. Отнеситесь к нему как к полезной (хотя и непрошеной) подсказке.
Если результаты не соответствуют ожидаемым, документируйте свои предположения и выясните, почему они не соответствуют действительности. Основная причина ошибок в том, что программист не знает, чего ожидать на каждом шаге выполнения сценария. Это типично для начинающих администраторов, которые пытаются, например, использовать сценарии, заимствованные из Интернета. Уделив время изучению сценария, вы не только ускорите отладку, но и больше узнаете о PowerShell и сможете успешно создавать собственные сценарии в будущем, а умение выполнять отладку всегда пригодится в работе.
Дон Джоунз ([email protected]) - инструктор по PowerShell (www.windowsitpro.com/go/DonJonesPowerShell), имеет звание MVP; автор более 35 книг, выступает на таких технологических конференциях, как Microsoft TechEd и Windows Connections
Отладка в Windows PowerShell
Во время написания программы или скрипта любой начинающий программист столкнется с проблемой где ему нужно повторить код дважды и в этот могут помочь функции в Powershell . Функции так же называют методами и процедурами. Кроме многократного использования они так же полезны для выделения одной части скрипта от другой, хоть она и выполняется один раз. Методы описанные ниже существуют во множестве языках и работают по похожему сценарию.
Создание
Представим, что каждое утро вы проверяете 50 последних логов за 14 часов журнала Application с помощью этой команды:
Get-EventLog -LogName Application -Newest 50 | where TimeWritten -ge (Get-Date).AddHours(-14)
Команда не очень сложная, но в скором времени ее надоест писать. Для сокращения этой работы ее можно выделить в отдельную функцию:
Function Get-DayLog { Get-EventLog -LogName Application -Newest 50 | where TimeWritten -ge (Get-Date).AddHours(-14) }
Любая функция обязательно должна состоять из трех вещей:
- function - объявляет и говорит что после нее будет название;
- имя функции - название, по которому мы будем ее вызывать. В нашем случае имя Get-DayLog;
- скобки - обозначают начало и конец выражения.
После написания функции она вызывается по имени:
Get-DayLog
Учитывая, что нам может потребоваться получить данные не за последние 14 часов и более чем за 50 дней нам может потребуется изменить ее передав параметры.
Именование
Не обязательно использовать имя такого же плана, как принято в Powershell, то есть вместо "Get-DayLog" можно писать "daylog". Такой подход рекомендуем и является распространенной практикой, который поможет отличить запуск сторонней программы от функции.
Функции в Powershell всегда именуются по следующему признаку. Первое слово это глаголы типа:
- Get - получить;
- Set - изменить;
- Install - установить;
- New - создать.
Второе имя - это существительное, как в случае выше DayLog(дневной лог). У Microsoft есть утвержденный список глаголов, который доступен по ссылке на английском языке. Если вы не будете придерживаться этих правил и захотите добавить свою функцию (командлет или модуль) в один из репозиториев, то он может не пройти модерацию.
Передача параметров
Чаще всего функции принимают какой-то объект и возвращают. Для примера может потребоваться изменить время, когда эти логи созданы и их количество. В существующей функции такой возможности нет. Вы можете править код каждый раз, но это не подход программиста. Что бы такая возможность появилась в функции нужно добавить параметры, которая она будет принимать:
Function Get-DayLog ($param1,$param2) { Get-EventLog -LogName Application -Newest $param1 | where TimeWritten -ge (Get-Date).AddHours($param2) }
Параметры функции обозначаются в круглые скобки и пишутся после названия функции и до выражения.
Теперь, для вызова функции, требуется передавать два параметра:
Get-DayLog -param1 50 -param2 -14
При вызове функции мы передаем два обязательных параметра со значениями. Эти значения, внутри функции, будут доступны под названиями $param1 и $param2. Эти переменные мы передаем в команду получения и фильтрации логов.
Установка значений по умолчанию
В нашей задаче, чаще всего, мы получаем только 50 последних логов и нам не хочется указывать их каждый раз. Если мы не будем указывать этот параметр в существующей функции, то получим ошибку. Что бы этого избежать нужно указать значение по умолчанию. На примере ниже я присвоил $param1 значение 50. Оно будет использоваться только в том случае, если мы не используем этот параметр при вызове:
Function Get-DayLog ($param1=50,$param2) { Get-EventLog -LogName Application -Newest $param1 | where TimeWritten -ge (Get-Date).AddHours($param2) } Get-DayLog -param2 -7
Мы должны всегда указывать ключ param2, что добавляет немного работы. Что бы это исправить достаточно поменять их местами:
Function Get-DayLog ($param2,$param1=50) { Get-EventLog -LogName Application -Newest $param1 | where TimeWritten -ge (Get-Date).AddHours($param2) } Get-DayLog -7 1 Get-DayLog -7
Как видно на примере, если мы не указываем ключи param1 и param2 важна последовательность, так как именно в такой последовательности они будут присвоены переменным внутри функций.
Возвращение значений
В отличие от других языков, если мы присвоим переменной $result результат функции Get-DayLog, то она будет содержать значения:
$result = Get-DayLog -7 1
Это будет работать до тех пор, пока мы не решим изменить функцию присвоив переменные:
Function Get-DayLog ($param2,$param1=50) { $events = Get-EventLog -LogName Application -Newest $param1 | where TimeWritten -ge (Get-Date).AddHours($param2) } $result = Get-DayLog -7 $result $events
Мы не можем получить результат используя переменную $result, так как функция не выводит информацию, а хранит ее в переменной $events. Вызывая $events мы тоже не получаем информацию, так как тут работает понятие "область видимости переменных".
Так как функции это отдельная часть программы вся логика и ее переменные не должны касаться другой ее части. Область видимости переменных подразумевает это же. Все переменные, созданные внутри функции остаются в ней же. Эту ситуацию можно исправить с помощью return:
Function Get-DayLog ($param2,$param1=50) { $events = Get-EventLog -LogName Application -Newest $param1 | where TimeWritten -ge (Get-Date).AddHours($param2) return $events } $result = Get-DayLog -7 $result
Я бы рекомендовал всегда возвращать значения через return, а не использовать вывод используя команды типа Write-Output внутри функции. Использование return останавливает работу функции и возвращает значение, а это значит что его не стоит ставить по середине логики если так не планировалось.
Возвращаемых значений может быть несколько. Для примера создадим функцию, которая будет считать зарплату и налог:
Function Get-Salary ($Zarplata) { $nalog = $Zarplata * 0.13 $zarplata_bez_nds = $Zarplata - $nalog return $nalog,$zarplata_bez_nds } Get-Salary -Zarplata 100000
Я вернул оба значения разделив их запятой. По умолчанию всегда возвращается массив. это набор не именованных параметров. Более подробно о них мы уже писали.
В случае с массивами, что бы добавит надпись о зарплате, и налоге нужно использовать индексы:
$result = Get-Salary -Zarplata 100000 # Определяем тип данных $result.GetType() Write-Host "это зарплата" $result Write-Host "это налог" $result
Возвращаться может любой тип данных. Например мы можем использовать другой тип данных хэш таблицы, которые в отличие от массивов именованные:
Function Get-Salary ($Zarplata) { $nalog = $Zarplata * 0.13 $zarplata_bez_nds = $Zarplata - $nalog return @{"Налог"=$nalog;"Зарплата"=$zarplata_bez_nds;} } Get-Salary -Zarplata 100000
Использование массивов
Передача массивов в виде параметров
В предыдущих статьях было множество примеров по работе с массивами и хэш таблицами. Их же, как и любой другой тип данных, мы можем передавать в функцию. Для примера все команды Powershell, которые имеют ключ ComputerName, могут выполняться удаленно. Большинство таких команд могут принимать в виде значений массивы, то есть нам не обязательно передавать поочередно имена компьютеров.
Функция будет принимать массив с именами компьютеров и возвращать все остановленные сервисы. Я так же объявлю этот тип строгим, для наглядности, хотя и без этого в любом случае сработает:
Function Get-ServiceStopped ($Computers){ $services = Get-Service -ComputerName $Computers | where Status -eq Stopped return $services } Get-ServiceStopped "127.0.0.1","localhost"
Массивы так же работают по индексам, что позволяет передавать больше параметров. Такой способ не релевантный, но может когда-то пригодиться.
Function Get-ServiceStopped ($Computers){ $services = Get-Service -ComputerName $Computers | where Status -eq $Computers[-1] return $services } Get-ServiceStopped "127.0.0.1","localhost","Stopped"
Хэш таблицы
Параметры хэш таблиц и могут передаваться не просто в функцию, а как параметры командлетов. Добавим в нашу функцию запуск сервиса, если он остановлен:
Function Get-ServiceStopped ($Params){ $services = Get-Service @Params | where Status -eq Stopped $services = Start-Service $services return $services } Get-ServiceStopped @{Name="WinRM";ComputerName=@("127.0.0.1","localhost")}
Знак @ в команде объявляет, что данные хэш таблицы будут использоваться как параметры команды. Важно, чтобы их имена соответствовали настоящим параметрам.
Условия
Нет никаких ограничений на использования условий. Это бывает достаточно удобно, когда функция должна вернуть разные значения.
Ниже приведен пример, где в зависимости от скорости загрузки основной части сайта будет возвращен разный ответ. Если скорость ответа меньше 76 миллисекунды нормальная, в случае если более долгого ответа вернется другой результат:
Function Get-SiteResponse { # Начало отсчета $start_time = Get-Date # Выполнение запроса $request = Invoke-WebRequest -Uri "https://сайт" # Фиксирование окончания выполнения $end_time = Get-Date # Высчитываем разницу во времени $result = $end_time - $start_time # Проверка и возвращение результата if ($result.Milliseconds -lt 76) { return "Скорость ответа нормальная " + $result.Milliseconds} else{ return "Сайт отвечает долго " + $result.Milliseconds } } Get-SiteResponse
Switch
Мы уже говорили про в предыдущих статьях. Если коротко, то это более удобные условия. Используя предыдущий пример, но со Switch, это будет выглядеть так:
Function Get-SiteResponse { # Начало отсчета $start_time = Get-Date # Выполнение запроса $request = Invoke-WebRequest -Uri "https://сайт" # Фиксирование окончания выполнения $end_time = Get-Date # Высчитываем разницу во времени $result = $end_time - $start_time # Проверка и возвращение результата switch($result.Milliseconds) { {$PSItem -le 76} { return "Скорость ответа нормальная " + $result.Milliseconds} default { return "Сайт отвечает долго " + $result.Milliseconds } } } Get-SiteResponse
Другой пример Switch это вызов функции в зависимости от переданных параметров. На примере ниже я вызываю функцию, в которой находится Switch. В эту функцию я передаю имя компьютера, которое проверяется на упоминание указанных фраз и вызывает соответствующую функцию. Каждая функция, которая устанавливает обновления, возвращает значение в Switch, а затем происходит return внутри нее:
Function Install-SQLUpdates { # делаем установку return "Установка обновлений на SQL сервер прошла успешно" } function Install-ADUpdates { # делаем установку return "Установка обновлений на сервер AD прошла успешно" } function Install-FileServerUpdates { # делаем установку return "Установка обновлений на файловый сервер прошла успешно" } function Make-Switch ($computer) { # Проверка имени компьютера $result = switch($computer){ {$computer -like "SQL*"} {Install-SqlUpdates} {$computer -like "AD*"} {Install-ADUpdates} {$computer -like "FileServer*"} {Install-FileServerUpdates} default {"Такого типа компьютеров нет"} } return $result } Make-Switch "AD1"
Со switch так же удобно передавать булевы значения. В примере ниже если указан ключ -On сервис включится, а если его нет выключится:
Function Switch-ServiceTest ($on) { if ($on) {Write-Output "Сервис включен"} else {"Сервис выключен"} } Switch-ServiceTest -On Switch-ServiceTest
Передача через конвейер или Pipeline
Вы наверняка работали через команды Powershell, которые позволяли использовать конвейер следующим образом:
Get-Process -Name *TestProc* | Stop-Process
Если мы захотим использовать подход описанный выше, создав новые команды в виде функций, то конвейер не будет работать:
Function Get-SomeNum { # Генерация числа $num = Get-Random -Minimum 5 -Maximum 10 return $num } function Plus-SomeNum ($num) { Write-Host "Прибавление числа " $num $num += $num return $num } Get-SomeNum Plus-SomeNum 5 Get-SomeNum | Plus-SomeNum
Выполнив следующую команду мы сможем увидеть, что значения, которые могут приниматься через конвейер помечаются специальным атрибутом:
Get-Help Stop-Process -Parameter Name
Таких атрибутов всего два:
- ValueFromPipelineByPropertyName - получение значения из конвейера по имени;
- ValueFromPipeline - получение через конвейер только значения.
Кроме этого, внутри нашей функции, мы должны добавить специальный блок Process. Наш скрипт в итоге будет выглядеть так:
Function Get-SomeNum { $num = Get-Random -Minimum 5 -Maximum 10 return $num } function Plus-SomeNum { Param ( $num) process { Write-Host "Прибавление числа " $num $num += $num return $num } } 1..5 | Plus-SomeNum Get-SomeNum | Plus-SomeNum
Атрибут расширения функции, который добавляет некоторые возможности в функции позволяя им работать как команду.
Если бы мы не указали блок Process функция бы вернула только последней результат из массива 1..5:
Если наши команды будут иметь критический характер, такой как удаление, или через конвейер может передаваться несколько значений, то стоит использовать атрибут ValueFromPipelineByPropertyName. Таким образом мы исключим попадания через конвейер случайного значения. На примере ниже я изменил
Function Get-SomeNum { $num = Get-Random -Minimum 5 -Maximum 10 $object = @{num=$num} return $object } function Plus-SomeNum { Param ( $num) process { Write-Host "Прибавление числа " $num $num += $num return $num } } Get-SomeNum | Plus-SomeNum @{num=5} | Plus-SomeNum @{bad=5} | Plus-SomeNum
Как уже писалось ValueFromPipelineByPropertyName принимает только именованные параметры и в случае с именем "bad" мы получаем ошибку:
- Не удается привязать объект ввода к любым параметрам команды, так как команда не принимает входные данные конвейера
- The input object cannot be bound to any parameters for the command either because the command does not take pipeline input or the input and its properties do not match any of the parameters that take pipeline input.
Причем передавать именованные параметры через хэш таблицы мы не можем, только через pscustomobject.
Вы можете указывать сразу два атрибута таким образом:
Это позволит использовать и значение с именем, если оно указано либо без него. Это не спасет вас от ситуации, если вы передаете параметр с другим именем:
Передача через конвейер нескольких значений
Для примера рассмотрим ситуацию, где нам нужно передать через конвейер два значения. Если Get-SomeNum будет возвращать массив, то через конвейер у нас будет проходить каждое число по отдельности. Это еще один повод использовать именованные параметры:
Function Get-SomeNum { $number1 = Get-Random -Minimum 5 -Maximum 10 $number2 = Get-Random -Minimum 1 -Maximum 5 $object = @{num1=$number1;num2=$number2} return $object } function Plus-SomeNum { Param ( $num1, $num2) begin {$num1 += $num1 $num2 = $num2 * $num2} process { return @{"Результат сложения"=$num1; "Результат умножения"=$num2} } } Get-SomeNum | Plus-SomeNum
Windows PowerShell является мощным средством и может выполнять практически все, что хочет человек на своем компьютере. Но единственная проблема заключается в том, что это инструмент командной строки и не имеет графического интерфейса. Тем не менее, это может быть полезно, когда интерфейс на основе графического интерфейса не работает или перестает отвечать. К сожалению, главным является тот факт, что обычному пользователю не хватает знаний об использовании PowerShell в полной мере. Но сегодня мы попытаемся обсудить 10 лучших команд PowerShell, которые могут помочь пользователю сделать больше в Windows 10.
Команды PowerShell, которые помогут пользователю сделать больше
Прежде чем мы начнем, необходимо подчеркнуть, что некоторые из этих командлетов могут переключать определенные параметры или конфигурацию на вашем компьютере. Командлет — это сценарий PowerShell, который выполняет одну функцию. Поэтому, чтобы быть в безопасности, сначала создайте точку восстановления системы. Если во время выполнения одного из следующих командлетов что-то пойдет не так, вы всегда сможете восстановить свой компьютер.
Мы рассмотрим командлеты , которые могут выполнять следующие действия:
- Запустите приложение UWP.
- Получить справку о любом командлете.
- Получите похожие команды.
- Найти определенный файл.
- Прочитайте содержимое файла.
- Найти информацию обо всех услугах на компьютере.
- Найти информацию обо всех процессах на компьютере.
- Установка политики выполнения.
- Скопируйте файл или каталог.
- Удалить файл или каталог.
1] Запустите приложение UWP
PowerShell — отличный инструмент, который можно использовать для запуска приложений UWP за считанные секунды. Но главное заключается в правильном выполнении команды. Ты можешь использовать
Start-Process "ms-settings:"
Команда просто для запуска приложения Windows Настройки UWP. Вы можете узнать больше о других URI для других приложений UWP здесь на microsoft.com.
2] Получите справку о любом командлете
Если вы когда-либо не понимаете, какую команду вы должны использовать для выполнения определенной задачи. Или то, что делает конкретный командлет, вам не нужно беспокоиться. Вы можете просто использовать командлет Get-Help, чтобы сделать это. Вы можете использовать его следующими способами:
Get-Help Получить помощь Get-Help -Full Get-Help -Example Get-Help *
Здесь первая запись расскажет вам, как использовать этот командлет. Вторая запись даст вам простое резюме конкретного командлета. Третья запись даст подробную информацию о соответствующем командлете. Четвертая запись будет содержать все, что показывает третий командлет, но добавит пример того, как использовать этот командлет. И, наконец, пятый командлет перечислит каждую команду, которая доступна для вашего использования.
3] Получить похожие команды
Чтобы найти команды аналогичного типа или содержащие в себе определенную фразу, вы можете использовать командлет Get-Command . Однако в нем не перечислен каждый командлет в PowerShell, поэтому вы используете некоторые конкретные фильтры. Вы можете использовать следующие команды:
Get-Command -Name Get-Command -CommandType
Первый командлет поможет вам найти командлет с определенной фразой, а второй — отфильтровать командлеты, выполняющие определенную функцию.
4] Поиск определенного файла
Если вам нужно найти определенный файл или каталог в определенном месте, вы можете использовать командлет Get-Item . Вы можете использовать его как
Get-Item
перечислить содержимое конкретного пути.
5] Прочитайте содержимое файла
Get-Content
6] Прочтите информацию обо всех службах на компьютере .
Вы можете использовать командлет Get-Service , чтобы перечислить все службы, запущенные или остановленные на вашем компьютере. Кроме того, вы можете использовать следующие связанные командлеты для выполнения их соответствующих функций:
Start-Service Стоп-Service Suspend-Service Resume-Service Рестарт-Сервис
7] Читайте информацию обо всех процессах на компьютере
Подобно командлету Get-Service, вы можете использовать командлет Get-Process , чтобы вывести список всех процессов, запущенных на вашем компьютере.В качестве альтернативы вы можете использовать следующие связанные командлеты для выполнения соответствующих функций:
Запуск процесса Stop-Process Служба ожидания
8] Настройка политики выполнения
Хотя в PowerShell поддерживается создание и выполнение сценариев, существуют ограничения для каждого из них в рамках некоторых мер безопасности. Вы можете переключить уровень безопасности на любой из 4 уровней. Вы можете использовать командлет Set-ExecutionPolicy , а затем любой из уровней безопасности, указанных в
Set-ExecutionPolicy Неограниченный Set-ExecutionPolicy Все подписано Set-ExecutionPolicy Удаленная подпись Set-ExecutionPolicy Restricted
Здесь политики сверху вниз варьируются от самого низкого до самого высокого уровня безопасности.
9] Скопируйте файл или каталог
Пользователь может использовать командлет Copy-Item
Copy-Item "E: \ TWCTest.txt" -Destination "D: \"
10] Удалить файл или каталог
Подобно командлету Copy-Item, пользователь может использовать командлет Copy-Item для копирования одного файла или каталога в другое место назначения. Синтаксис этого командлета
Remove-Item "E: \ TWCTest.txt"
Закончим работу с выводом данных.
В том случае, если нам не нужен вывод информации на экран консоли (допустим, она просто для нас лишняя, и нам просто нужно, чтобы определенные команды отработали без вывода результатов на экран), мы можем воспользоваться командлетом Out-Null .
Что будет, если к хорошо известному командлету Get-Process добавить Out-Null ?
Get-Process | Out-Null
Пример действия Out-Null в PowerShell
Как видим, не произошло ровным счетом ничего. А, точнее будет сказать, ничего видимого для наших глаз. Командлет Get-Process отработал, но мы не захотели ознакомиться с результатами его работы. Конечно, данное действие было бессмысленным.
Можно привести пример более осмысленного действия. Перейдем в корень диска C и создадим там каталог primer.
cd c:\ mkdir primer
Как видим, PowerShell вывел нам содержимое только что созданного каталога. Если нам это не нужно, можно использовать Out-Null .
mkdir primer | Out-NullИтак, Out-Null это полезный инструмент для совершения тех действий, которые должны выполняться что называется «под капотом».
