Глава 6. Конвейер: соединение команд

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

Вы уже наблюдали это в действии в таких командах как Dir | more. Вы передаёте получаемый от команды Dir вывод в команду more; эта команда more получает такой список каталога и отображает его по странице за раз. PowerShell принимает такое понятие конвейера и расширяет его с большим эффектом.

Поначалу применение конвейера в PowerShell может показаться похожим на то, как работают оболочки UNIX и Linux. Однако не дайте себя обмануть. Как вы поймёте из следующих нескольких глав, реализация конвейера PowerShell намного богаче и современнее.

PowerShell предоставляет несколько мощных способов экспорта данных в полезные форматы, такие как TXT, CSV, JSON и XML (Extensible Markup Language). В своём рабочем процессе вам может потребоваться экспорт данных из Azure Active Directory или из облачного хранилища. В данной главе мы пройдёмся по такому процессу передачи данных. Мы начнём с получения данных из некой простой встроенной команды для упрощения своего процесса, однако само понятие остаётся тем же самым.

Давайте начнём с запуска нескольких простых команд. Затем мы изучим как соединять их вместе. Вот несколько команд, которыми мы можем воспользоваться:

Мы будем придерживаться этих команд, поскольку они лёгкие и простые. Мы снабдили вас псевдонимами Get-Process и Get-Commandв скобках. Для Get-History мы определили параметр -count со значением 10, а потому он выдаст лишь последние 10 записей истории.

Что вы видите? Когда мы запускаем Get-Process, на нашем экране появляется некая таблица с несколькими столбцами сведений (Рисунок 6.2).

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

Экспорт в это именно то, где становятся удобными конвейер и вторая команда:

Get-Process | Export-CSV procs.CSV
		

Аналогично передаче Dir в more, мы перенаправляем свой процесс в Export-CSV. Этот второй командлет обладает обязательным позиционным параметром (обсуждались в Главе 3), который мы применяем для определения своего файла вывода. Поскольку Export-CSV естественный командлет PowerShell, он знает как транслировать получаемый Get-Process в стандартный файл CSV.

Двинемся далее и откроем полученный файл в Visual Studio Code для просмотра полученных результатов, как это отражено на Рисунке 6.3.

code ./procs.CSV
		

Самая первая строка этого файла содержит заголовки столбцов, а последующие строки перечисляют все сведения для имеющихся различных процессов, запущенных в вашем компьютере. Вы можете пересылать вывод практически любого командлета Get- в Export-CSV и получать исключительные результаты. Вы также можете отметить, что получаемый файл CSV содержит намного больше сведений чем обычно отображается на экране. Это преднамеренно. Оболочка знает, что она не способна разместить на экране эти сведения, поэтому она применяет предоставленную Microsoft конфигурацию для выбора под отображение на экране наиболее важной информации. В последующих главах мы покажем вам как переопределять такую конфигурацию для отображения всего что вы пожелаете.

После того как все сведения сохранены в файле CSV, вы запросто можете отправлять его коллегам через электронную почту и просить просмотреть их через PowerShell. Для этого им придётся импортировать ваш файл:

Import-CSV procs.CSV
		

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

Давайте допустим, что вы желаете выполнить экспорт сведений о своих процессах и включит информацию об их потоках. Сведения о потоках это то, что носит название вложенных свойств в объекте process. Давайте взглянем (Рисунок 6.4). Обратите внимание на то, что Select-Object Threads сообщает PowerShell отображать только свойство Threads. Более глубоко мы рассмотрим Select-Object в Главе 8.

Когда вы попробуете выполнить экспорт при помощи ConvertTo-CSV, свойство Threads будет обладать значением System.Diagnostics.ProcessThreadCollection. итак, нам необходим иной способ экспорта данных когда мы нуждаемся во вложенных свойствах под свойством Threads.

PowerShell также обладает командлетом ConvertTo-Json, который создаёт файл JSON, который всегда сохраняет такие вложенные свойства. Большинство языков программирования обладают библиотеками, понимающими JSON. У вас также имеется соответствующий командлет ConvertFrom-Json. И командлет ConvertFrom, и командлет ConvertTo (также как и ConvertFrom-CSV с ConvertTo-CSV) и производят, и потребляют строки в своём конвейере. Именно такая команда служит для преобразования процессов в JSON, применяя Out-File для сохранения получаемых результатов в файл:

PS C:\Scripts\> Get-Process | ConvertTo-Json | Out-File procs.json
		

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

PS C:\Scripts\> Get-Content ./procs.json | ConvertFrom-Json
		

Если вы исполните данную команду, вы отметите что ваши данные в совершенно ином формате по сравнению с тем когда вы запускаете команду Get-Process. В своём следующем разделе мы покажем вам как их обрабатывать. Рисунок 6.5 отображает некую выдержку того как выглядят получаемые свойства Threads при экспорте в JSON.

В своём предыдущем разделе вы обратили внимание на то, что возвращаемые ConvertFrom-Json отображаются совершенно иначе по сравнению с тем, когда вы получаете их первоначальной командой. Это обусловлено тем, что ваши объекты не обладают одним и тем же типом (в Главе 8 мы рассмотрим объекты). Существует команда для экспорта данных и получения обратно самих первоначальных объектов.

PowerShell обладает командлетом Export-Clixml, который создаёт естественный файл CLI XML, позволяющий PowerShell реконструировать свои первоначальные объекты (или нечто очень близкое к ним). Clixml уникален для PowerShell, и хотя все программы технически способны понимать производимый им XML, будет лучше когда результаты применяются самим PowerShell. У вас также имеется соответствующий командлет Import-Clixml. И командлет импорта, и командлет экспорта (также как и Import-CSV с Export-CSV) ожидают названия файла в качестве обязательного параметра.

Содержит ли PowerShell иные команды импорта или экспорта? Вы можете отыскать их воспользовавшись командлетом Get-Command и предписав параметр -Verb либо с Import, либо с Export.

Мы обсудили файлы CSV, JSON и XML, но что если мы пожелаем просто текстовый файл для сохранения в нём ваших данных? Давайте взглянем на команду Out-File. Она получает содержащиеся в своём конвейере данные и отправляет их в простой файл - ниже приводится некий текстовый файл для нашего примера:

Get-ChildItem | Select-Object Name | Out-File process.txt
		

И файлы CSV, и файлы CLIXML могут быть полезными дня неизменных моментальных снимков сведений, совместного применения этих снимков с прочими и просмотра этих снимков позднее по времени. Фактически, Compare-Object предлагает великолепный способ их применения.

Прежде всего выполните help Compare-Object и прочтите получаемую подсказку для этого командлета. Мы хотим чтобы вы, в частности, уделили три параметра: -ReferenceObject, -DifferenceObject и -Property.

Compare-Object разработан для получения двух наборов сведений и их сопоставления друг с другом. Например, допустим вы выполнили Get-Process в двух компьютерах, располагающихся бок о бок. Тот компьютер, который настроен в точности тем способом, расположен слева и является Эталонным компьютером. Компьютер справа может быть точно таким же, либо может чем- то отличаться; это Не совпадающий компьютер. После выполнения команды в каждом из них, вы начинаете с двух таблиц информации, причём ваше задание состоит в определении тех отличий, которые имеются между этими двумя.

Поскольку это просматриваемые вами процессы, вы всегда ожидаете наблюдать отличия в таких моментах как числа использования ЦПУ и памяти, поэтому мы игнорируем такие столбцы. Фактически, мы сосредоточиваемся на столбце Названий, поскольку мы хотим определить содержит ли Не совпадающий компьютер какие- то дополнительные процессы или их меньше по сравнению с Эталонным компьютерам. Для сравнения всех названий процессов из двух таблиц может потребоваться некоторое время, но от вас этого не потребуется - именно это для вас сделает Compare-Object. Допустим, вы располагаетесь за Эталонным компьютером и выполняете это:

Get-Process | Export-CliXML reference.xml
		

Мы предпочитаем применять CLIXML вместо CSV для сравнения подобного, поскольку CLIXML содержит больше сведений чем простой файл CSV. Затем вы можете перенести этот файл XML на Не совпадающий компьютер и выполняем такую команду:

Compare-Object -Reference (Import-Clixml reference.xml)
➥-Difference (Get-Process) -Property Name
		

Поскольку наш предыдущий шаг слегка хитроумен, мы поясним что происходит:

Вот получаемый в наше проверке вывод:

PS C:\Scripts>Compare-Object -ReferenceObject (Import-Clixml ./procs.xml) 
     ➥ -DifferenceObject (Get-Process) -Property name
 
name            SideIndicator
----            -------------
nano            =>
pwsh            =>
		

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

Между прочим, вам следует знать, что Compare-Object обычно плохо справляется со сравнением текстовых файлов. Хотя в прочих операционных системах и оболочках имеется команда Compare-Object, в явном виде предназначенная для сравнения текстовых файлов, в PowerShell команда Compare-Object работает иначе. Как именно иначе вы увидите в лабораторных занятиях для этой главы.

Всякий раз когда у вас имеется хорошо отформатированный вывод,к примеру, выработанные Get-Command или Get-Process таблицы - вы можете сохранить их в неком файле или даже на бумаге. Как правило, вывод командлета направляется на ваш экран, на который PowerShell ссылается как на хост, однако вы можете изменять куда поступает этот вывод. Мы уже показали вам один способ выполнения этого:

Dir > DirectoryList.txt
		

Символ > это добавленное в PowerShell сокращение для предоставления совместимости с оболочкой Bash. На практике, при исполнении вами данной команды вот что происходит под капотом PowerShell:

Dir | Out-File DirectoryList.txt
		

Вы можете исполнить ту же самую команду самостоятельно, вместо использования синтаксиса >. Зачем нам это По той причине, что Out-File к тому же предоставляет дополнительные параметры, которые позволяют указывать альтернативные кодировки символов (например, UTF-8 или Unicode), добавлять содержимое в конец файла и тому подобное. По умолчанию, созданные Out-File файлы обладают шириной столбцов 80, что означает, что иногда PowerShell способен изменять вывод команды чтобы он умещался в пределах 80 символов. Такое изменение может приводить к тому, что содержимое файла будет выглядеть иначе, нежели при выполнении той же самой команды на ваш экран. Чтобы узнать как вы можете изменять ширину файла вывода на нечто, отличающееся от 80 символов, ознакомьтесь с файлом подсказки Out-File.

PowerShell обладает разнообразными командами Out-. Одна из них носит название Out-Default, и именно она применяется когда вы не определяете иной командлет Out-. Если вы исполняете

Dir 
		

технически вы запускаете

Dir | Out-Default
		

даже если вы и не отдаёте себе отчёт в этом. Out-Default это ничто иное, чем направление содержимого в Out-Host, что означает что вы выполняете

Dir | Out-Default | Out-Host
		

незаметно для себя. Out-Host отображает сведения на вашем экране. Какие иные команды Out- вы способны обнаружить?

Out-Null и Out-String обладают особым применением, которое мы не будем рассматривать, но вы можете прочесть их файлы подсказок и посмотреть содержащиеся в этих файлах подсказки.

Хотите производить отчёты HTML? Направьте свою команду в ConvertTo-Html. Эта команда производит достойно форматированный, общий HTML, который отображается в любом веб- браузере. Это выглядит просто, однако вы можете сослаться на файл Вложенных таблиц стилей (CSS, Cascading Style Sheets) для определения более привлекательного форматирования, если это требуется. Обратите внимание, что такая команда не требует имени файла:

Get-Process -Id $PID | ConvertTo-Html
		

В мире PowerShell глагол Export подразумевает, что вы берёте данные, преобразовываете их в некий иной формат и сохраняете этот другой формат в неком виде хранилища, например в файле. Значение глагола ConvertTo подразумевает лишь некую часть этого процесса: преобразование в иной формат, однако не сохраняя это в файле. Когда вы выполнили нашу предыдущую команду, вы получаете экран заполненный HTML, что, скорее всего, н было тем, что вы желали. Остановитесь на секунду; можете ли вы представить как вы получаете это HTML в текстовом файле на диске?

Данная команда выполняет эту хитрость:

Get-Process | ConvertTo-Html | Out-File processes.html
		

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

PowerShell снабжается и прочими командлетами ConvertTo-, включая ConvertTo-CSV и ConvertTo-Xml. Как и в случае с ConvertTo-Html, они не создают файл на диске; они транслируют вывод команды в CSV или HTML, соответственно. Вы можете перенаправлять такой преобразованный вывод в Out-File для последующего сохранения на диске, хотя и было бы короче воспользоваться Export-CSV или Export-Clixml, поскольку они выполняют и преобразование, и сохранение.

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

Get-Process | Stop-Process
		

Вы можете представит себе что сделает данная команда? Мы скажем вам: вы можете уничтожить критически важные процессы. Она выполнит выборку всех процессов и затем попытается завершить каждый из них. Она способна получить некий критически важный процесс, такой как /usr/sbin/coreaudiod в macOS, а ваш компьютер больше не будет способен воспроизводить звук. Если вы запустили PowerShell внутри виртуальной машины и хотите побаловаться, следуйте дальше и попробуйте выполнить эту команду.

Дело в том, что командлеты с одним и тем же существительным (в данном случае Process) часто способны обмениваться между собой сведениями. Обычно вам приходится указывать конкретное название определённого процесса вместо того чтобы пытаться остановить их все:

Get-Process -Name bash | Stop-Process
		

Задания (jobs) предоставляют нечто аналогичное: получаемый из Get-Job вывод может быть переправлен в такие командлеты как Stop-Job, Receive-Job, Wait-Job и тому подобные. Подробнее задания мы рассмотрим в Главе 14.

Как вы можете предположить, определённые правила ограничивают то, какие команды могут соединяться друг с другом. Например, когда вы ищите такую последовательность как Get-Process | New-Alias, вы, скорее всего, не ожидаете что она сделает нечто чувствительное (хотя она и способна выполнить нечто несуразное). В Главе 7 мы окунёмся в те правила, которые руководят тем как команды способны соединяться друг с другом.

Нам бы хотелось ознакомиться ещё с одним моментом относительно таких командлетов как Stop-Job и Stop-Process. Эти командлеты изменяют неким образом саму систему, а все командлеты, которые изменяют вашу систему обладают внутренне определённым уровнем влияния (impact level). Сам создатель командлета устанавливает такой уровень влияния и он может быть изменён. Соответствующая оболочка обладает надлежащей установкой $ConfirmPreference, которая по умолчанию настроена на High. Чтобы увидеть настройку своей оболочки наберите следующее название установки:

PS /Users/jsnover> $ConfirmPreference
High
		

Вот как это работает: когда внутренний уровень влияния командлета равен или выше настройки $ConfirmPreference оболочки, такая оболочка автоматически спросит: "Are you sure?" (Вы уверены?) когда данный командлет попробует что- то предпринять. Если вы применяете виртуальную машину чтобы попробовать крушащую- ваш - компьютер команду, которую мы упоминали ранее, у вас, скорее всего спросят "Are you sure?" для каждого процесса. Когда внутренний уровень влияния меньше чем настройка $ConfirmPreference оболочки, вы не получите автоматического предложения на ввод "Are you sure?". Однако вы можете принудить свою оболочку спрашивать вас каждый раз, уверены ли вы:

Get-Process | Stop-Process -Confirm
		

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

Аналогичным параметром выступает -WhatIf. Он поддерживается всеми поддерживающими -Confirm командлетами. Такой параметр -WhatIf не включается по умолчанию, однако вы можете задавать его всякий раз, когда пожелаете:

PS C:\Scripts > Get-Process | Stop-Process –WhatIf
What if: Performing operation "Stop-Process" on Target "conhost (1920)
".
What if: Performing operation "Stop-Process" on Target "conhost (1960)
".
What if: Performing operation "Stop-Process" on Target "conhost (2460)
".
What if: Performing operation "Stop-Process" on Target "csrss (316)".
		

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

Одним из распространённых замешательств в PowerShell связано с командами Export-CSV и Export-Clixml. Технически говоря, обе команды создают текстовые файлы. Получаемый в каждой из команд вывод можно просмотреть в Visual Studio Code, как это отражено на Рисунке 6.3. Но надо признать, что этот текст пребывает определённом формате - будь то CSV, либо XML.

Собственно путаница происходит когда некто просит считать эти файлы обратно в оболочку. Воспользуетесь ли вы Get-Content (либо его type псевдонимом)? Скажем, допустим, вы сделали это:

PS C:\Scripts>Get-Process | Select-Object -First 5 | export-CSV processes.CSV 
➥ -IncludeTypeInformation
		

Обратите внимание на установленный переключатель -IncludeTypeInformation; мы вернёмся к нему позднее. Теперь попробуем считать это обратно воспользовавшись Get-Content:

PS C:\Scripts>Get-Content ./processes.CSV                                    
#TYPE System.Diagnostics.Process "Name","SI","Handles","VM","WS","PM","NPM","Path",
"Parent","Company","CPU","FileVersion","ProductVersion","Description","Product","__NounName","SafeHandle",
"Handle","BasePriority","ExitCode","HasExited","StartTime","ExitTime","Id","MachineName","MaxWorkingSet",
"MinWorkingSet","Modules","NonpagedSystemMemorySize64","NonpagedSystemMemorySize","PagedMemorySize64",
"PagedMemorySize","PagedSystemMemorySize64","PagedSystemMemorySize","PeakPagedMemorySize64",
"PeakPagedMemorySize","PeakWorkingSet64","PeakWorkingSet","PeakVirtualMemorySize64","PeakVirtualMemorySize",
"PriorityBoostEnabled","PriorityClass","PrivateMemorySize64","PrivateMemorySize","ProcessName",
"ProcessorAffinity","SessionId","StartInfo","Threads","HandleCount","VirtualMemorySize64","VirtualMemorySize",
"EnableRaisingEvents","StandardInput","StandardOutput","StandardError","WorkingSet64","WorkingSet",
"SynchronizingObject","MainModule","MainWindowHandle","MainWindowTitle","Responding",
"PrivilegedProcessorTime","TotalProcessorTime","UserProcessorTime","Site","Container"
"","87628","0","0","0","0","0",,,,,,,,,"Process",
"Microsoft.Win32.SafeHandles.SafeProcessHandle","0","0",,"False",,,"0",".",,,"System.Diagnostics.ProcessModuleCollection",
"0","0","0","0","0","0","0","0","0","0","0","0","False",
"Normal","0","0","",,"87628",,"System.Diagnostics.ProcessThreadCollection","0","0","0",
"False",,,,"0","0",,,"0","","True",,,,,
		

Мы усекли свой предыдущий вывод, но в нём ещё много подобного. Выглядит как мусор, не так ли? Вы просматриваете сырые данные CSV. Наша команда не пытается интерпретировать или разбирать полученные данные вовсе. В противоположность с результатами Import-CSV:

PS C:\Scripts>Import-CSV ./processes.CSV
 NPM(K)    PM(M)      WS(M)     CPU(s)      Id  SI ProcessName
 ------    -----      -----     ------      --  -- -----------
      0     0.00       0.00       0.00       0 ...28 
      0     0.00       0.00       0.00       1   1 
      0     0.00       0.00       0.00      43  43 
      0     0.00       0.00       0.00      44  44 
      0     0.00       0.00       0.00      47  47
		

Намного лучше, ведь так? командлеты Import- уделяют внимание тому что содержится в самом файле, пытаясь интерпретировать это и создают отображение, которое выглядит во многом как вывод своей первоначальной команды (в данном случае Get-Process). Чтобы осуществить это с Export-CSV, вам необходимо воспользоваться переключателем -IncludeTypeInformation. Обычно затем, когда вы создали при помощи Export-CSV некий файл, вы считываете его при помощи Import-CSV. Если вы создали его при помощи Export-Clixml, вы обычно считываете его применяя Import-Clixml. Используя данные команды попарно вы достигаете лучшего результата. Пользуйтесь Get-Content только когда вы считываете текстовый файл и не желаете чтобы PowerShell пытался выполнять синтаксический разбор предоставляемых данных - то есть когда вы желаете работать с сырыми данными.

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