Комментарии powershell: PowerShell — Комментирование | powershell Tutorial

Как вы комментируете код в PowerShell?

Как вы комментируете код в PowerShell (1.0 или 2.0)?

835

автор: Peter Mortensen

7 ответов

в PowerShell V1 есть только # чтобы сделать текст после него комментарием.

# This is a comment in Powershell

В PowerShell V2 <# #> можно использовать для комментариев блока и более конкретно для комментариев справки.

#REQUIRES -Version 2.0

<#
.SYNOPSIS
    A brief description of the function or script. This keyword can be used
    only once in each topic.
.DESCRIPTION
    A detailed description of the function or script. This keyword can be
    used only once in each topic.
.NOTES
    File Name      : xxxx.ps1
    Author         : J.P. Blanc ([email protected])
    Prerequisite   : PowerShell V2 over Vista and upper.
    Copyright 2011 - Jean Paul Blanc/Silogix
.LINK
    Script posted over:
    http://silogix.fr
.EXAMPLE
    Example 1
.EXAMPLE
    Example 2
#>
Function blabla
{}

более подробное объяснение .SYNOPSIS и .* посмотреть в разделе about_comment_based_help.

примечание: эти комментарии функции используются Get-Help командлет и может быть поставлен перед ключевым словом Function или внутри {} до или после самого кода.

94

автор: adamleerich

однострочные комментарии начинаются с хэш-символ, все справа от # будет проигнорирован:

# Comment Here

в PowerShell 2.0 и выше можно использовать многострочные комментарии блоков:

<# 
  Multi 
  Line 
#> 

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

Get-Content -Path <# configuration file #> C:\config.ini

Примечание: потому что PowerShell поддерживает Завершение вы должны быть осторожны с копированием и вставкой Space + TAB перед комментарии.

здесь

# Single line comment in Powershell

<# 
--------------------------------------
Multi-line comment in PowerShell V2+ 
-------------------------------------- 
#>

в PowerShell ISE вы можете нажать Ctrl+J открыть Начать Отсекать menü и выберите комментарий блок:

8

автор: Martin Brandl

вы можете сделать:

 (Some basic code) # Use "#" after a line and use:

 <#
    for more lines
    ...
    ...
    ...
    ..
    .
 #>

3

автор: Mister X CT

PowerShell. Пользовательские функции для пользователей / Хабр

Привет! Довольно часто в своей работе приходиться пользоваться самостоятельно написанными функциями и таскать куски кода между разными скриптами. На Хабре уже есть довольно хорошая статья про Повторное использование кода от Mroff, но была необходимость пойти немного дальше, задокументировать и как-то описать свои функции. Как оказалось, поиск выдавал довольно сухую информацию в основном по общей структуре функции и не более того. Упорство было вознаграждено, и я решил поделиться полученной информацией. Добро пожаловать под кат, где мы научимся вносить в свои функции информацию для потомков и коллег.

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

Function TestPath ([String]$Path)
        {
                Return(Test-Path $Path)
        }

В общем то ничего сложного, как и в других языках задали имя TestPath, в круглых скобках через запятую скормили переменные $Path, выполнили в теле функции необходимые действия и при необходимости вернули Return() значение. А как быть, когда нужно работать с несколькими переменными? Выходов всегда больше одного – постоянно давать мнемонические коды или делать описание переменной, давайте рассмотрим, как это делается:

Function TestPath
        {
                PARAM (
                [PARAMETER(Mandatory=$True,Position=0,HelpMessage = "Путь до проверяемого ресурса",ParameterSetName='Path')]$Path
                )
                Return(Test-Path $Path)
        }

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

Mandatory – Принимает два значения True обязательный для заполнения и False необязательный;

HelpMessage – Справка по переменной;

ParameterSetName – Имя переменной к которой относятся данные параметры;

Position – Позиция переменной при вызове функции;

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

((Get-Command TestPath).ParameterSets.Parameters | Where-Object Name -eq Path).HelpMessage

PowerShell ответит нам одной строкой в которой будет написано: Путь до проверяемого ресурса.

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

Немного усложним задачу и подготовим функцию информация о которой по запросу Get-Help будет выводиться в полном объеме:

Function WriteToLog {
    <#
    .SYNOPSIS
        Вывод сообщения в консоль и в файл лога.
    .DESCRIPTION
        Данная функция выводит переданную строку в лог файл и в консоль PowerShell
    .EXAMPLE
        #WriteToLog -Str "Данное сообщение будет выведено в консоль красным цветом и в файл C:\Log\log.txt" -FileName 'C:\Log\log.txt' -Color Red
    .EXAMPLE
        #WriteToLog -Str "Данное сообщение будет выведено в консоль цветом по умолчанию (White) и в файл C:\Log\log.txt" -FileName 'C:\Log\log.txt'
    .PARAMETER Str
        Строка, которую необходимо вывести (обязательный параметр)
    .PARAMETER FileName
        Имя файла лога (обязательный параметр)
    .PARAMETER Color
        Цвет текста сообщения в консоли PowerShell (По умолчанию цвет текста белый (White))
    #>
    param (
        [PARAMETER(Mandatory=$True,Position=0)][String]$Str,
        [PARAMETER(Mandatory=$True,Position=1)][String]$FileName,
        [PARAMETER(Mandatory=$False,Position=2)][String]$Color='White'
        )
        Write-Host $Str -ForegroundColor $Color
        If ((Test-Path $FileName) -eq $True)
            {
                Add-Content -Path $FileName -Value $Str
            }
        Else
            {
                Set-Content -Path $FileName -Value $Str
            }
    }

После выполнения данного кода команда Get-Help ‘WriteToLog’ -ShowWindow выведет нам следующее окно.
Давайте разберем что же мы такого написали:

<##> – В данном блоке написаны параметры для справки PowerShell.

.SYNOPSIS – блок для краткого описание функции

.DESCRIPTION – блок для полного описание функции

.EXAMPLE – блок для примера использования функции, может быть несколько

.PARAMETR Имя параметра – блок для описания переменной, для каждой переменной свой блок.

Как вы могли заметить текстовый комментарий начинается со следующей строки после ключевого названия раздела и может быть многострочным. Окончанием комментария считается закрывающий тег #> или следующий блок.

param () – блок для описания переменных, в котором мы указали их порядок и необходимость передачи параметров при вызове функции. Для переменной $Color мы присвоили значение по умолчанию’White’.

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

Спасибо что дочитали до конца.

Работа с объектами, собственные классы / Блог компании RUVDS.com / Хабр

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

Оглавление:

Объекты в PowerShell
Просмотр структуры объектов
Фильтрация объектов
Сортировка объектов
Выделение объектов и их частей
ForEach-Object, Group-Object и Measure-Object
Создание объектов .NET и COM (New-Object)
Вызов статических методов
Тип PSCustomObject
Создание собственных классов

Объекты в PowerShell

Напомним, что объект — это совокупность полей данных (свойств, событий и т.д.) и способов их обработки (методов). Его структура задается типом, который как правило базируется на использующихся в унифицированной платформе .NET Core классах. Также есть возможность работать с объектами COM, CIM (WMI) и ADSI. Свойства и методы нужны для выполнения различных действий над данными, кроме того в PowerShell объекты можно передавать как аргументы в функции и командлеты, присваивать их значения переменным, а также существует механизм композиции команд (конвейер или pipeline). Каждая команда в конвейере передает свой вывод следующей поочередно — объект за объектом. Для обработки можно использовать скомпилированные командлеты или создавать собственные расширенные функции, чтобы производить различные манипуляции с объектами в конвейере: фильтрацию, сортировку, группировку и даже изменение их структуры. Передача данных в таком виде имеет серьезное преимущество: принимающей команде не нужно заниматься синтаксическим разбором потока байтов (текста), вся нужная информация легко извлекается с помощью обращения к соответствующим свойствам и методам.

Просмотр структуры объектов

Для примера запустим командлет Get-Process, позволяющий получить информацию о работающих в системе процессах:

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

Get-Process | Get-Member

Здесь мы уже видим тип и структуру, а с помощью дополнительных параметров можем, например, вывести только свойства попавшего на вход объекта:

Get-Process | Get-Member -MemberType Property

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

Фильтрация объектов

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

Where-Object { блок сценария }

Результатом выполнения блока сценария в операторных скобках должно быть логические значение. Если оно истинно ($true) попавший на вход командлету Where-Object объект будет передан по конвейеру дальше, в противном случае (значение $false) он будет удален. Для примера выведем список остановленных служб Windows Server, т.е. таких, у которых свойство Status имеет значение «Stopped»:

Get-Service | Where-Object {$_.Status -eq "Stopped"}

Здесь мы снова видим текстовое представление, но при желании понять тип и внутреннее устройство проходящих через конвейер объектов нетрудно:

Get-Service | Where-Object {$_.Status -eq "Stopped"} | Get-Member

Сортировка объектов

При конвейерной обработке объектов часто возникает необходимость их сортировки. В командлет Sort-Object передаются имена свойств (ключей сортировки), а он возвращает упорядоченные по их значениям объекты. Вывод запущенных процессов несложно отсортировать по затраченному процессорному времени (свойство cpu):

Get-Process | Sort-Object –Property cpu

Параметр -Property при вызове командлета Sort-Object можно не указывать — он используется по умолчанию. Для обратной сортировки применяется параметр -Descending:

Get-Process | Sort-Object cpu -Descending

Выделение объектов и их частей

Командлет Select-Object позволяет выделить определенное количество объектов в начале или в конце конвейера с помощью параметров -First или -Last. С его помощью можно выбрать единичные объекты или определенные свойства, а также создать на их основе новые объекты. Разберем работу командлета на простых примерах.

Следующая команда выводит информацию о 10 процессах, потребляющих максимальный объем оперативной памяти (свойство WS):

Get-Process | Sort-Object WS -Descending | Select-Object -First 10

Можно выделить только определенные свойства проходящих через конвейер объектов и создать на их основе новые:

Get-Process | Select-Object ProcessName, Id -First 1

В результате работы конвейера мы получим новый объект, структура которого будет отличаться от структуры возвращаемых командлетом Get-Process. Убедимся в этом при помощи Get-Member:

Get-Process | Select-Object ProcessName, Id -First 1 | Get-Member

Обратите внимание, что Select-Object возвращает единичный объект (-First 1), у которого всего два указанных нами поля: их значения были скопированы из первого переданного в конвейер командлетом Get-Process объекта. На использовании Select-Object основан один из способов создания объектов в сценариях PowerShell:

$obj = Get-Process | Select-Object ProcessName, Id -First 1
$obj.GetType()

С помощью Select-Object можно добавлять объектам вычисляемые свойства, которые необходимо представить в виде хэш-таблицы. При этом значение ее первого ключа соответствует имени свойства, а значение второго — значению свойства для текущего элемента конвейера:

Get-Process | Select-Object -Property ProcessName, @{Name="StartTime"; Expression = {$_.StartTime.Minute}}

Посмотрим на структуру проходящих через конвейер объектов:

Get-Process | Select-Object -Property ProcessName, @{Name="StartTime"; Expression = {$_.StartTime.Minute}} | Get-Member

ForEach-Object, Group-Object и Measure-Object

Для работы с объектами существуют и другие командлеты. Для примера расскажем о трех наиболее полезных:

ForEach-Object позволяет выполнить код на языке PowerShell для каждого объекта в конвейере:

ForEach-Object { блок сценария }

Group-Object группирует объекты по значению свойства:

Group-Object PropertyName

Если запустить его с параметром -NoElement, можно узнать количество элементов в группах.

Measure-Object агрегирует различные сводные параметры по значениям полей объектов в конвейере (вычисляет сумму, а также находит минимальное, максимальное или среднее значение):

Measure-Object -Property PropertyName -Minimum -Maximum -Average -Sum

Обычно рассмотренные командлеты используются в интерактивном режиме, а в скриптах чаще создаются функции с блоками Begin, Process и End.

Создание объектов .NET и COM (New-Object)

Есть множество программных компонентов с интерфейсами .NET Core и COM, которые пригодятся системным администраторам. С помощью класса System.Diagnostics.EventLog можно управлять системными журналами непосредственно из Windows PowerShell. Разберем пример создания экземпляра этого класса при помощи командлета New-Object с параметром -TypeName:

New-Object -TypeName System.Diagnostics.EventLog

Поскольку мы не указали определенный журнал событий, полученный экземпляр класса не содержит данных. Чтобы это изменить, необходимо во время его создания вызвать специальный метод-конструктор при помощи параметра -ArgumentList. Если мы хотим получить доступ к журналу приложений, в конструктор следует передать строку «Application» в качестве аргумента:

$AppLog = New-Object -TypeName System.Diagnostics.EventLog -ArgumentList Application
$AppLog

Обратите внимание: выходные данные команды мы сохранили в переменной $AppLog. Хотя в интерактивном режиме обычно используются конвейеры, написание сценариев часто требует сохранения ссылки на объект. Кроме того основные классы .NET Core содержатся в пространстве имен System: PowerShell по умолчанию ищет в нем указанные типы, поэтому написание Diagnostics.EventLog вместо System.Diagnostics.EventLog вполне корректно.

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

$AppLog | Get-Member -MemberType Method

Скажем очищается он методом Clear() при наличии прав доступа:

$AppLog.Clear()

Командлет New-Object применяется и для работы с СОМ-компонентами. Их довольно много — от поставляемых с сервером сценариев Windows библиотек до приложений ActiveX, таких, например, как Internet Explorer. Чтобы создать СОМ-объект, требуется задать параметр -ComObject с программным идентификатора ProgId нужного класса:

New-Object -ComObject WScript.Shell
New-Object -ComObject WScript.Network
New-Object -ComObject Scripting.Dictionary
New-Object -ComObject Scripting.FileSystemObject

Для создания собственных объектов с произвольной структурой использование New-Object выглядит слишком архаичным и громоздким, этот командлет используется для работы с внешними по отношению к PowerShell программными компонентами. В следующих статьях этот вопрос будет разобран более подробно. Помимо объектов .NET и COM мы также изучим объекты CIM (WMI) и ADSI.

Вызов статических методов

Экземпляры некоторых классов .NET Core создать невозможно: к их числу относятся System.Environment и System.Math. Они являются статическими и содержат только статические свойства и методы. По сути это справочные библиотеки, которые используются без создания объектов. Сослаться на статический класс можно через литерал, заключив имя типа в квадратные скобки. При этом если посмотреть на структуру объекта с помощью Get-Member, мы увидим тип System.RuntimeType вместо System.Environment:

[System.Environment] | Get-Member

Для просмотра только статических элементов нужно вызвать Get-Member с параметром -Static (обратите внимание на тип объекта):

[System.Environment] | Get-Member -Static

Для доступа к статическим свойствам и методам используются два идущих подряд двоеточия вместо точки после литерала:

[System.Environment]::OSVersion

Или

$test=[System.Math]::Sqrt(25) 
$test
$test.GetType()

Тип PSCustomObject

Среди многочисленных доступных в PowerShell типов данных отдельно стоит упомянуть PSCustomObject, предназначенный для хранения объектов с произвольной структурой. Создание такого объекта с помощью командлета New-Object считается классическим, но громоздким и устаревшим способом:

$object = New-Object  –TypeName PSCustomObject -Property @{Name = 'Ivan Danko'; 
                                          City = 'Moscow';
                                          Country = 'Russia'}

Посмотрим на структуру объекта:

$object | Get-Member

Начиная с PowerShell 3.0 доступен и другой синтаксис:

$object = [PSCustomObject]@{Name = 'Ivan Danko'; 
                                          City = 'Moscow';
                                          Country = 'Russia'
}

Получить доступ к данным можно одним из эквивалентных способов:

$object.Name

$object.'Name'

$value = 'Name'
$object.$value

Приведем пример преобразования в объект существующей хэштаблицы:

$hash = @{'Name'='Ivan Danko'; 'City'='Moscow'; 'Country'='Russia'}
$hash.GetType()
$object = [pscustomobject]$hash
$object.GetType()

Один из недостатков объектов этого типа — порядок их свойств может поменяться. Чтобы этого избежать, необходимо использовать атрибут [ordered]:

$object = [PSCustomObject][ordered]@{Name = 'Ivan Danko'; 
                                          City = 'Moscow';
                                          Country = 'Russia'
}

Есть и другие варианты создания объекта: выше мы рассмотрели использование командлета Select-Object. Осталось разобраться с добавлением и удалением элементов. Сделать это для объекта из предыдущего примера довольно просто:

$object | Add-Member –MemberType NoteProperty –Name Age  –Value 33
$object | Get-Member

Командлет Add-Member позволяет добавлять ранее созданному объекту $object не только свойства, но и методы посредством использования конструкции «-MemberType ScriptMethod»:

$ScriptBlock = {
    # код 
}
$object | Add-Member -Name "MyMethod" -MemberType ScriptMethod -Value $ScriptBlock
$object | Get-Member

Обратите внимание: для хранения кода нового метода мы использовали переменную $ScriptBlock типа ScriptBlock.

Для удаления свойств используется соответствующий метод:

$object.psobject.properties.remove('Name')

Создание собственных классов

В PowerShell 5.0 появилась возможность определения классов с использованием характерного для объектно-ориентированных языков программирования синтаксиса. Для этого предназначено служебное слово Class, после которого следует задать имя класса и описать его тело в операторных скобках:

class MyClass
{
    # тело класса
}

Это настоящий тип .NET Core, в теле которого описываются его свойства, методы и другие элементы. Рассмотрим пример определения простейшего класса:

class MyClass 
{
     [string]$Name
     [string]$City
     [string]$Country
}

Для создания объекта (экземпляра класса) используется командлет New-Object, либо литерал типа [MyClass] и псевдостатический метод new (конструктор по умолчанию):

$object = New-Object -TypeName MyClass

или

$object = [MyClass]::new()

Проанализируем структуру объекта:

$object | Get-Member

Не стоит забывать про область видимости: нельзя ссылаться на имя типа в виде строки или использовать литерал типа за пределами скрипта или модуля, в котором определен класс. При этом функции могут возвращать экземпляры класса (объекты), которые будут доступны вне модуля или скрипта.

После создания объекта заполним его свойства:

$object.Name = 'Ivan Danko'
$object.City = 'Moscow'
$object.Country = 'Russia'
$object

Отметим, что в описании класса задаются не только типы свойств, но и их значения по умолчанию:

class Example
{
     [string]$Name = 'John Doe'
}

Описание метода класса напоминает описание функции, но без использования служебного слова function. Как и в функции, в методы при необходимости передаются параметры:

class MyClass 
{
     [string]$Name
     [string]$City
     [string]$Country
     
     #описание метода
     Smile([bool]$param1)
     {
         If($param1) {
            Write-Host ':)'
         }
     }
}

Теперь представитель нашего класса умеет улыбаться:

$object = [MyClass]::new()
$object.Smile($true)

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

class MyClass2 : MyClass
{
      #тело нового класса, базовым для которого является MyClass
}
[MyClass2]::new().Smile($true)

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

Часть 1: основные возможности Windows PowerShell
Часть 2: введение в язык программирования Windows PowerShell
Часть 3: передача параметров в скрипты и функции, создание командлетов

Доступ к внешним объектам / Блог компании RUVDS.com / Хабр

В операционных системах Windows поддерживаются различные объектные инфраструктуры. Для доступа к ним можно использовать интерфейсы прикладного программирования (API), но разработка полноценных приложений не всегда оправдана. В PowerShell существуют специальные командлеты, позволяющие обращаться к объектам .NET, COM, WMI (CIM) и ADSI в интерактивном режиме. В четвертой части цикла мы изучили основы с упором на классы .NET Core, а сейчас хотим углубить тему и разобрать особенности взаимодействия PowerShell с внешними объектами.

Оглавление:

Работа с JSON, XML и CSV
Работа с WMI и CIM
Работа с COM-объектами
Работа со службой каталогов ADSI
Форматирование вывода

Работа с JSON, XML и CSV

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

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

$user = @"
{
   "firstName": "Ivan",
   "lastName": "Danko",
   "address": {
       "streetAddress": "Kremlin",
       "city": "Moscow"
   },
   "phoneNumbers": [
       "+7 495 1234567",
       "+7 499 1234567"
   ]
}
"@ | ConvertFrom-Json

Обратная задача решается сходным образом:

$file = Get-ChildItem C:\Windows\System32\notepad.exe
$file.VersionInfo | ConvertTo-Json

Полученную строку в формате JSON нетрудно отправить другому приложению по сети. Это может быть, например, некий RESTful сервис. Работа с командлетами ConvertFrom-Csv, ConvertTo-Csv и ConvertTo-Xml строится примерно так же, предлагаем читателям изучить ее самостоятельно.

Для работы с XML и CSV нам потребуются и другие командлеты:

Используя эти инструменты нужно понимать, что преобразование бинарного объекта в текстовый формат сохраняет только значение его свойств, но не методы. Преобразование данных в формате JSON, XML или CSV в объект .NET с помощью PowerShell возможно, только если они валидны.

Работа с WMI и CIM

Windows Management Instrumentation (WMI) — это разработанная в Microsoft и адаптированная под Windows реализация стандарта WBEM (Web-Based Enterprise Management). В его основе лежит идея создания универсального решения для мониторинга распределенной информационной среды предприятия и управления ее компонентами. Структура данных WBEM в свою очередь основана на Common Information Model (CIM), реализующей объектно-ориентированный подход к представлению компьютерных систем. Дальнейшая разработка и поддержка WMI в Windows прекращена, Microsoft рекомендует использовать для управления инфраструктурой сходный механизм — объекты CIM. Для работы ними в PowerShell 3.0 появились специальные командлеты, которые мы будем рассматривать параллельно с аналогами для WMI. Если в коде есть вызовы командлетов для работы с WMI, его по возможности стоит переписать.

В рамках модели CIM (она же используется в WMI) данные операционной системы представлены в виде классов со свойствами и методами. Классы группируются в иерархически упорядоченные и логически связанные по технологии или области управления пространства имен. Существует корневое пространство имен Root, в котором имеются подпространства: CIMv2, Default, Secutiry и WMI. Для однозначной идентификации экземпляра класса (объекта) и описания состояния соответствующего ему ресурса используются свойства класса, которые обычно доступны только для чтения. Для управления ресурсом используются методы.

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

[\\ComputerName\NameSpace][:ClassName][.KeyProperty1=Value1][,KeyProperty2=Value2]…]

где
ComputerName — имя компьютера;
NameSpace — пространство имен;
ClassName — имя класса;
KeyProperty1=Value1, KeyProperty2=Value2 — свойства объекта и значения, по которым он идентифицируется.

До появления PowerShell простого инструмента работы с WMI не существовало. Для доступа к объектам приходилось писать довольно сложные программы на высокоуровневых языках (C++, Visual Basic, Java Script) либо изучать оболочку WMIC (WMI Command Line, поддержка которой также прекращена) с собственным языком. Через PowerShell объекты WMI доступны рядовому пользователю из командной строки или в сценариях. Для начала подключимся к подсистеме WMI и получим список доступных классов с помощью командлета Get-WmiObject (псевдоним gwmi). Чтобы получить список классов CIM, используйте командлет Get-CimClass.

Get-CimClass
Get-WmiObject -List

Мы вывели список классов на локальном компьютере, но можно подключиться и к удаленному:

Get-CimClass -ComputerName IP-адрес 
Get-CimClass -ComputerName Имя_компьютера

или

Get-WmiObject -ComputerName IP-адрес -List
Get-WmiObject -ComputerName Имя_компьютера -List

По умолчанию командлеты Get-CimClass и Get-WmiObject подключаются к пространству имен Root\CIMV2, в котором хранится большое количество классов для управления системой. Для смены пространства имен применяется параметр -Namespace:

Get-CimClass -Namespace Root
Get-WmiObject -Namespace Root -List

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

Get-WmiObject Win32_Service

Как и в случае с объектами других типов, список свойств и методов выводится при помощи Get-Member. К методам объекта WMI можно обращаться напрямую или с помощью командлета Invoke-WmiMethod. Также к объектам WMI можно применять командлеты для сортировки, фильтрации, группировки и т.д.

Get-WmiObject Win32_Service | Get-Member

Для получения объектов (экземпляров классов) CIM используется командлет Get-CimInstance. В отличие от WMI, результирующие CIM-объекты (resultant object или экземпляры класса) не содержат методов класса. Поскольку извлечь метод непосредственно невозможно, придется вызывать командлет Invoke-CimMethod. Рассмотрим класс Win32_Service — запущенные в системе службы) и его экземпляр для службы spooler на локальной машине:

Get-CimInstance Win32_service -filter "Name='spooler'" 

Посмотрим на структуру результирующего объекта:

Get-CimInstance Win32_service -filter "Name='spooler'" | Get-Member

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

Есть и специфичный для WMI инструментарий: язык запросов WMI Query Language (WQL), напоминающий SQL. WQL-запрос для поиска всех стартующих при запуске системы служб выглядит так:

select * from win32_service where startmode="Auto"

Из PowerShell они выполняется следующим образом:

Get-WmiObject -Query 'select * from win32_service where startmode="Auto"'

Работа с COM-объектами

Для обеспечения взаимодействия между приложениями в Windows была разработана технология связывания и внедрения объектов (Object Linking and Embedding или OLE). Позже появилась технология OLE Automation, с помощью которой приложения клиенты автоматизации могли вызывать функции других приложений — серверов автоматизации. OLE и OLE Automation были основаны на базовой технологии Component Object Model (COM), которая предлагает единый двоичный стандарт для программных компонентов. Созданные по нему и зарегистрированные в операционной системе объекты могут использоваться в других приложениях с помощью исполняемых файлов или динамических библиотек.

Примерно с середины девяностых годов вместо OLE стал использоваться другой термин — ActiveX. До появления платформы .NET технология ActiveX считалась ключевой, а объекты COM до сих пор активно используются для интеграции приложений в Windows — многие продукты Microsoft и сторонних разработчиков являются серверами автоматизации и предоставляют через них доступ к своим сервисам. Для обращения к объектам используется ProgID — символьный идентификатор, который присваивается им при регистрации в реестре Windows. Он имеет следующий вид:

Библиотека_типов.Класс.Версия

Версия обычно не указывается:

Библиотека_типов.Класс

Несколько примеров доступных ProgID: InternetExplorer.Application (приложение Internet Explorer), Word.Application (приложение Microsoft Word), WScript.Shell (класс Shell из объектной модели сервера сценариев Windows Script Host или WSH).

Создать экземпляр объекта можно с помощью рассмотренного в предыдущей статье командлета New-Object, а посмотреть его структуру — с помощью Get-Member:

$myshell = New-Object -ComObject WScript.Shell
$myshell | Get-Member

Для работы с объектами используются свойства и методы. Скажем, чтобы создать на рабочем столе пользователя ярлык, нужно вызвать метод CreateShortcut():

$link = $myshell.CreateShortcut("$Home\Desktop\Home.lnk")

Обратите внимание, что ярлык — это тоже объект COM:

$link | Get-Member

Нам остается заполнить его свойства и сохранить:

$link.TargetPath = $Home
$link.Save()

Таким способом мы создали ярлык на рабочем столе активного пользователя, а теперь разберем работу с внешними сервисами автоматизации на примере COM-объекта Shell.Application. С его помощью можно автоматизировать некоторые действия в проводнике Windows:

$myshell=New-Object -ComObject Shell.Application

или для краткости:

$myshell=New-Object -com Shell.Application
$myshell | Get-Member

У объекта Shell.Application есть довольно много различных методов управления окнами. К примеру, для отображения содержимого заданного каталога используется Explore():

$myshell.Explore("c:\")

Справочная система вызывается с помощью метода Help():

$myshell.Help()

Есть также три метода для вызова диалоговых окон поиска: FindFiles(), FindComputer() и FindPrinter().

$myshell.FindFiles()
$myshell.FindComputer()
$myshell.FindPrinter()

Открыть диалоговое окно запуска программ можно с помощью метода FileRun(), а для вызова окна установки даты/времени нужен метод SetTime(). Есть, к примеру, методы для вызова окна настройки панели задач, элементов панели управления с указанием одного из доступных файлов cpl, для управления открытыми окнами:

$myshell.MinimizeAll()
$myshell.UndoMinimizeAll()
$myshell.TileHorizontally()
$myshell.TileVertically()

Метод Windows() позволяет получить доступ к коллекции открытых в проводнике или в браузере Internet Explorer окон. Посмотрим доступные для этой коллекции свойства и методы:

$myshell.Windows() | Get-Member

Существуют и другие полезные COM-объекты, количество которых зависит от установленного в системе ПО. Когда-то основным средством автоматизации в Windows считался сервер сценариев WSH, объектная модель которого включает и COM-объекты: предназначенный для работы с сетевыми функциями WScript.Network и уже упомянутый нами WScript.Shell. Последний не только создает ярлыки на рабочем столе, с его помощью можно, например, выводить информационные окна с сообщениями и кнопками, переключаться между приложениями, запускать программы или имитировать нажатия клавиш.

Работа со службой каталогов ADSI

Под каталогом в общем случае подразумевается источник информации, в котором хранятся данные о некоторых объектах. Под службой каталога мы понимаем часть распределенной компьютерной системы, позволяющий обращаться к хранящимся объектам и манипулировать ими. Служба каталога может объединять данные об объектах сети и осуществляющих манипуляцию ими сервисов — она представляет собой единую точку входа для взаимодействия с сетевыми ресурсами. В гетерогенной компьютерной сети таких служб может быть множество: локальный диспетчер SAM (Security Account Manager) для не входящих в домен компьютеров, Active Directory и т.д.

Для взаимодействия с разными службами каталогов требуются различные инструменты, что создает определенные неудобства. Начиная с Windows 2000 корпорация Microsoft внедрила в операционные системы унифицированную технологию ADSI (Active Directory Service Interface) для не зависящего от конкретного сетевого протокола доступа. Чтобы находить объекты, для каталога определяется пространство имен. Поскольку разные службы каталогов используют различные способы именования, ADSI определяет позволяющее однозначно идентифицировать любой объект соглашение. Вводится понятие состоящих из двух частей строк связывания (binding string) или ADsPath. Первая часть имени определяет службу каталогов (провайдера ADSI), а вторая — расположение объекта в каталоге. Приведем примеры обозначения разных провайдеров ADSI:

LDAP:// используется для основанной на LDAP службы каталогов, в т.ч. для Active Directory;

WinNT:// используется для локальных компьютеров.

Специальных командлетов для работы с ADSI в PowerShell нет. Вместо них применяется оператор приведения типов [ADSI] после которого указывается строка связывания. Например, для подключения к пользователю Ivanov из домена test.ru нужна следующая конструкция:

$user = [ADSI]"LDAP://CN=Ivanov,DC=TEST,DC=RU"

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

$computer = [ADSI]"WinNT://."

Для примера создадим на локальной машине нового пользователя Ivanov:

$user = $computer.Create("user","Ivanov")
$user.Put("Description","Создан из PowerShell")
$user.SetInfo()

Теперь подключимся к нему:

$user1 = [ADSI]"WinNT://./Ivanov,user"
$user1.Description

Форматирование вывода

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

Format-Table форматирует вывод в виде таблицы, столбцы которой содержат значения свойств объекта или вычисляемые значения. Поддерживается возможность группировки данных;

Format-List выводит объект как список свойств, каждое из которых отображается на новой строке. Поддерживается возможность группировки данных;

Format-Custom форматирует вывод с использованием пользовательского представления;

Format-Wide форматирует объекты в виде широкой таблицы, в которой отображается только одно свойство каждого объекта.

Если ни один из перечисленных командлетов не вызван, применяется соответствующий типу отображаемых данных модуль форматирования. Правила отображения хранятся в конфигурационных файлах в формате XML с расширением .ps1xml, которые находятся в каталоге $PSHome. Их список можно получить с помощью следующей команды:

dir $pshome\*format*.ps1xm

Редактировать конфигурационные файлы вручную не рекомендуется, лучше создать собственные и включить их в список загружаемых с помощью командлета Update-FormatData. Если модуль форматирования по умолчанию для нужного типа не определен, PowerShell отображает на экране свойства объекта в виде списка.

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

Часть 1: Основные возможности Windows PowerShell
Часть 2: Введение в язык программирования Windows PowerShell
Часть 3: Передача параметров в скрипты и функции, создание командлетов
Часть 4: Работа с объектами, собственные классы

Включайте в сценарии PowerShell справочную информацию | Windows IT Pro/RE

Один из самых эффективных инструментов, которые помогают пользователям изучать механизмы оболочки PowerShell, — ее справочная система, и в первую очередь — команда Get-Help. Для изучающих среду PowerShell это одна из трех ключевых команд (остальные две — команды Get-Command и Get-Member). Если вам когда-либо доводилось работать с технологией PowerShell, вы, скорее всего, использовали команду Get-Help (или один из ее псевдонимов — help и man).

Справочная система загружается автоматически в ходе установки оболочки PowerShell, но если вы работаете с третьей или более новой версией этого продукта, не забудьте выполнить команду Update-Help при первом запуске PowerShell и регулярно запускать ее в дальнейшем. Дело в том, что Microsoft постоянно добавляет в справочную систему новые темы и исправляет ошибки в существующих темах, обнаруженные сотрудниками компании, а также другими пользователями. Предоставляя возможность выполнять команду Update-Help на вашей системе, Microsoft позволяет вам экономить значительную часть дискового пространства: ведь на вашу машину загружаются средства поддержки лишь того языка, который вы определили для своей системы, а не для всех языков, которые, возможно, указала система.

Сценарий PowerShell Get-Help

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

# Любой однострочный комментарий

  Сюда может быть включено любое число комментариев.
#>
 Как применять справочную информацию
 И как же использовать справочные данные в соответствии с вашим замыслом? В сущности все довольно просто. Достаточно определить в комментарии несколько ключевых слов и поместить комментарий в начало вашего сценария или в начало функции, и тогда каждый, кто будет пользоваться этим сценарием или функцией, сможет получить помощь точно таким же образом, каким вы получали нужные сведения с помощью команды Get-Help.
 Ключевые слова, которые вы будете использовать, называются тегами. Я применяю такие базовые теги:. SYNOPSIS,. DESCRIPTION и. EXAMPLE. Тег. SYNOPSIS позволяет дать краткое определение задачи, выполняемой сценарием или функцией. Тег. DESCRIPTION дает возможность представить более детальные сведения, а тег. EXAMPLE позволяет привести примеры применения вашего сценария или функции с тем, чтобы пользователь понял, как следует должным образом их вызывать. Ниже помещается раздел комментариев из сценария, который я использую для того, чтобы присвоить владельцам всех баз данных имя 'sa'.
 Вы также можете применять такие теги, как. PARAMETER для описания параметров, используемых в вашем коде,. INPUTS для описания типов объектов, которые могут быть переданы в ваш код по конвейеру, или. OUTPUTS для описания объектов, передаваемых на конвейер,. NOTES для передачи дополнительной информации,. LINK для передачи ссылок на дополнительные источники и т.д.
 Сценарий PowerShell get-Help Set-Database
 Включая подобного рода справочные данные в сценарии или функции, вы облегчите для тех, кто будет запускать их в дальнейшем, понимание того, какую задачу выполняет ваш код и как его следует использовать. Я обнаружил, что и мне самому эти данные помогают вспомнить, как пользоваться сценариями, которые я написал некоторое время назад.
 Включайте в сценарии PowerShell справочную информацию
Поделитесь материалом с коллегами и друзьями
Знакомство с PowerShell / Хабр
О том, что Microsoft в недавнем прошлом разродилась свежей оболочкой под названием PowerShell, я узнал еще с год назад. А вот попробовать, что это за зверь такой, никак руки не доходили. Но вот на днях на свежеустановленном Window Server 2008 я обнаружил эту штуку в составе предустановленных компонент, и любопытство все же взяло верх. Открыл, попробовал набить пару команд типа «help», «?» и т.п. — в результате был получен список всех команд (в жаргоне PowerShella, командлетов — cmdlets), оказавшийся достаточно объемным. Причем в списке фигурировали названия вроде ForEach, Where, которые не могли не вызвать интереса к тому, как эти конструкции можно потрогать. Полез за документацией и был приятно удивлен найденным переводам книг-учебников по сабжу (читал Windows PowerShell RU) — ссылки можно найти на блоге одного из активных участников комьюнити:
blogs.technet.com/abeshkov/archive/2008/12/24/3172943.aspx
Итак, после нескольких часов работы с PowerShell в голове отложилось:


 — PowerShell ничем не хуже обычного cmd.exe


 — Очень понравилась концепция объектно-ориентированной обработки данных, полученных из команд (командлетов). Порадовался, что можно зайти на ветку реестра, например, HKLM, как на обычный диск, командой cd HKLM: и побродить по нему все теми же ls и cd, читая атрибуты объектов реестра способом, аналогичным тому, который используется при чтении атрибутов файлов и директорий.


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


 — Не очень понравился синтаксис PowerShella с точки зрения личного неудобства — мне не нравится то, что нужно предварять имя любой переменной знаком $ или $_ в случае обращения к переданному объекту. Но, считаю, что к этим неудобствам вполне несложно привыкнуть, зато в коде сразу видны переменные + минимизируется число телодвижений.


 — Впечатлила возможность импорта/экспорта объектов в форматы CSV, XML (как я понял, происходит это с помощью механизма сериализации .NET), а тем более возможность взаимодействия с COM-объектами (в книге рассмотрен пример, в котором код в десяток строчек формирует раскрашенную таблицу и сохраняет её в XSLX-формате).


 — Описание возможностей интеграции CLS-совместимого .NET-кода с PowerShell оставило туманное впечатление о действительно большом достижении в области создания расширяемых механизмов администрирования. (С этим я еще не разбирался, самому интересно, насколько заявленная мощь соответствует действительности. Однако то, что можно прикрутить .NET-код, в любом случае радует).
В общем, впечатление позитивное и мне было бы интересно узнать отзывы тех людей, которые вплотную работают с этим инструментом.
Сбор информации о рабочих станциях через Powershell / Хабр
Сбор информации о рабочих станциях через Powershell.
Этот пост будет посвящен работе написанию скриптов на Powershell. Далее я предполагаю, что читатель уже сталкивался с написанием скриптов в windows среде. Итак:
Была у меня задача собрать некоторую информацию по пользовательским рабочим станциям в организации. Все станции в AD и пользователи тоже, что упрощает задачу. Есть контейнер, где находятся все станции, значит нужно пройтись по всем, взяв интересующую информацию, и отобразить результат. Раз так, то пишем скрипт. При написании, я стараюсь делать скрипт по частям. ИМХО для меня так проще и понятнее.
1. Нужен список станций. Его легко можно взять из AD такой вот командой:
Get-ADComputer -filter * -SearchBase «OU=Computers,ou=some-OU,dc=some-dc,dc=ru» 
Она выдаст все объекты из контейнера со всеми свойствами и т.п. Мне не нужны были все и я выбрал из них те, которые не выключены (Diasabled). Ставим в конвейер командлет
Where-Object {$_.enabled -eq $true} 
который выберет обьекты, у которых свойство enable равно true, то есть они включены. Далее, мне не нужны все свойства каждого обьекта, так что я выберу только свойство Имя (Name), поставив в конвейер командлет
Select-Object -Property Name
Список еще пригодится, так что создадим из него массив $enablePCs. Конечная команда будет такой
$enablePCs = Get-ADComputer -filter * -SearchBase «OU=Computers,ou=ru-moscow,ou=cee,dc=alico,dc=corp» | Where-Object {$_.enabled -eq $true} | Select-Object -Property Name
Теперь, если набрать в консоли $enablePCs, то выводом будет список имен всех компов.
Далее, можно подумать, что с этим списком уже можно работать, но нет. Части этих компов давно нет, часть выключена. Значит, нужно обрабатывать сортировать список далее. Я пошел по следующему пути: Если имя рабочей станции не удается разрешить в ip адрес, значит, такой станции уже нет, если удается, то можно ее попинговать. Если не пингуется, то скорее всего станция выключена. Тем самым можно составить список активных на данный момент станций, чтобы не пытаться разговаривать со стеной обращаться к неактивным хостам. Для разрешения я использовал метод resolve для функции [System.net.dns]. Получилась вот такая строка:
$dnsresult = [System.Net.Dns]::resolve(«$computername») 
Про $computername будет написано далее. После, нужно извлечь собственно ip адрес из результата
$ipaddress = $dnsresult.AddressList 
Далее проверяем адрес на доступность, используя стандартную системную функцию [system.net.networkinformation.ping] применяя к ней метод send. Команда следующая:
$pingfunc = (New-Object system.net.networkinformation.ping).send(«$ipaddress») 
Команда возвращает результат, и если его статус success, то рабочая станция доступна, и можно к ней обращаться. Тут уже на свой вкус, любые доступные действия в рамках ваших админских полномочий. Для примера покажу, как я проверял, на каких рабочих станциях установлен Chrome:
$chrome = dir «\\$ipaddress\C$\Program Files (x86)\Google\Chrome\Application\chrome.exe»


 if ($chrome -ne $null) {write-host «Host $computername is reacheble, use Chrome, and have ip $ipaddress»


 $sumchrome++}


 else {write-host «$computername is reacheble, do not use Chrome, and have ip $ipaddress»


 $pcwithoutchrome++} 
Переменные $sumchrome и $pcwithoutchrome нужны для подсчета общего числа тех или иных станций. Теперь сначала посмотрим логику всего скрипта.
<img src=»» alt=«image»/>
Теперь полный скрипт с комментариями.
$enablePCs = Get-ADComputer -filter * -SearchBase «OU=Computers,ou=someou,dc=somedomain,dc=corp» | Where-Object {$_.enabled -eq $true} | Select-Object -Property Name


 $sumunresolvePC = 0


 $sumchrome = 0


 $sumreacheblePC = 0


 $sumunreacheblePC = 0


 $pcwithoutchrome = 0
foreach ( $i in $enablePCs ) #начинаем цикл обработки объектов в массиве $enablePCs


 {


 $error.Clear() #очищаем буфер ошибок Powershell


 $erroractionpreference = «silentlycontinue» #подавляем вывод ошибок в консоль


 $dnsresult = 0


 $computername = $i.name #извлекаем имя станции


 $dnsresult = [System.Net.Dns]::resolve(«$computername»)
if (!$error) #условие, если предыдущая команда не была завершена ошибкой 


 {


 $ipaddress = $dnsresult.AddressList


 $pingfunc = (New-Object system.net.networkinformation.ping).send(«$ipaddress») #ping


 if ($pingfunc.Status -eq «success») 


 {


 $sumreacheblepc++ #плюсуем обще количество доступных станций


 $chrome = dir \\$ipaddress\C$\Program Files (x86)\Google\Chrome\Application\chrome.exe #проверка наличия Chrome


 If ($chrome -ne $null) {write-host «Host $computername is reachable, use Chrome, and have ip $ipaddress»
$sumchrome++ #плюсуем количество станций с Chrome


 }


 else {


 Write-host «$computername is reachable, do not use Chrome, and have ip $ipaddress»


 $pcwithoutchrome++ #плюсуем количество станций без Chrome


 }
}


 else {


 $sumunreacheblePC++ #плюсуем количество недоступных станций


 Write-Host «Host $computername is unreachable now, and have ip $ipaddress»
}


 }
else 


 {$sumunresolvePC++ #плюсуем количество неразрешенных станций


 write » I cannot resolve $computername :(«}


 }


 Write-Host «Total enabled PC = » $enablePCs.count 


 Write-Host «Total PC with Chrome = $sumchrome» 


 Write-Host «Total reachable PC = $sumreacheblePC» 


 Write-Host «Total Unreachable PC = $sumunreacheblePC» 


 Write-Host «Total PC Without Chrome = $pcwithoutchrome»


 write-host «Total unresolved PC = $sumunresolvepc»
Ну вот и все. Проверку наличия Chrome я описал для примера. Туда же можно включить много проверок и прочих полезных вещей, которые нельзя прописать в logonscript. Сам powershell я только начал изучать, если есть идеи по оптимизации, пишите, обсудим.
 комментариев Powershell — PowerShell — SS64.com 
 комментариев Powershell — PowerShell — SS64.com
 В PowerShell однострочные комментарии начинаются с символа решетки, все справа от # будет проигнорировано.
 #  комментарий 
 В PowerShell 2.0 и выше могут использоваться многострочные блочные комментарии:
 <#  комментарий  
 contines
 #>
 Многострочные комментарии обычно используются для добавления описательной справки в начале сценария, но также работают для встраивания текста комментария в команду.
 Справка на основе комментариев была также добавлена ​​в PS 2.0, что позволяет добавлять некоторые стандартизованные теги к комментариям к сценариям, которые позволяют сценарию взаимодействовать с Get-Help. 
 См. Этот шаблонный сценарий или полный список ключевых слов в справке about_Comment_Based_Help.
  Примеры 
 Copy-Item demo.msi C: \ install \ demo.msi # скопируйте установщик
 <#
   Этот скрипт будет говорить с вами на французском
   языковая функция на основе: www.example.com/powershell.html
   Последнее обновление: 1666-09-02
#>

Get-Content -Path <# файл конфигурации #> C: \ install \ app64.ini
 
 Используя встроенные комментарии, вы можете задокументировать аргументы командлета:
 PS C: \> Get-ChildItem <# перечислить элементы #> `
    -Path $ env: windir <# системной папки Windows #> `
    -Filter * .dll <# которые являются DLL #> `
    -Recurse <# и поиск во всех подпапках #> 
 Справка на основе комментариев 
 К функциям и скриптам можно добавлять разделы справки на основе комментариев.Это делается с помощью специальных ключевых слов для комментариев справки, которые начинаются с точки. Примеры этого приведены ниже. Вы можете добавить столько или меньше из них в свой сценарий, сколько необходимо, чтобы обеспечить соответствующий уровень подробной справки.
 DemoParam1
    Параметр DemoParam1 используется для определения значения blah, а также blah.

.PARAMETER  DemoParam2 
    Параметр DemoParam2 используется для определения значения blah, а также blah.

.ПРИМЕР
    Пример ниже делает бла
    PS C: \>  Пример 

.ПРИМЕР
    Другой пример

.ЗАМЕТКИ
    Автор:  Название 
    Последнее редактирование: гггг-мм-дд
    Версия 1.0 - начальный выпуск blah
    Версия 1.1 - обновление для бла

#> 
 Чтобы отобразить этот текст справки, используйте Get-Help 
 например 
 get-help ./script.ps1 
 get-help myfunction (это будет работать только после загрузки функции / получения точки)
 Где добавить справку на основе комментариев:
 Справка на основе комментариев для сценария   должна отображаться в начале сценария (ее также можно разместить в конце файла сценария, но только если сценарий не подписан.)
 Справка на основе комментариев для функции   может отображаться в одном из трех мест:
 В начале тела функции.
 В конце тела функции.
 Перед ключевым словом Function. Между последней строкой справки по функциям и ключевым словом Function не может быть более одной пустой строки.
 Большинство людей помещают все комментарии в начало скрипта / функции.
 Справка по умолчанию
 Если вы вызываете get-help для сценария, у которого нет справки на основе комментариев, но есть параметры, определенные с помощью оператора PARAM (), то get-help вернет эти сведения о параметрах.
 Также возможно получить более подробный набор текста справки по умолчанию, включив только <# .SYNOPSIS #> в верхней части скрипта.
 Дополнительные сведения см. В справке about_Comment_Based_Help.
 Копировать и вставить 
 Поскольку PowerShell поддерживает автозавершение табуляции, вам нужно быть осторожным при копировании и вставке символов пробела + TAB (особенно непосредственно перед разделителем комментария #).
 Пример:
 Демонстрация функций () {
 } # comment
 ^ Эта строка:}   # 
 при копировании / вставке в командную строку PowerShell происходит следующее:
 PS C: \ batch> Демонстрация функции () {
 >>}.\ aaardvaark.cmd # comment 
 >> 
 Термин ‘. \ Aaardvaark.cmd #’ не распознается как имя командлета, функции, файла сценария …
 Что происходит, так это то, что вкладка-пробел расширяется, чтобы соответствовать первому файлу в текущем каталоге, в данном случае aaardvaark.cmd. Если последовательность была <пробел> <вкладка> <пробел>, а первый файл был сценарием PowerShell или исполняемым файлом, то он действительно был бы запущен.
 Если пробел состоит только из символов  (или только из символов ), этого никогда не произойдет.
  # Теперь стой там, где работаешь, теперь лицом к западу 
 Подумайте о месте, где вы живете. Интересно, почему вы этого не сделали раньше # — REM ‘Stand’ 
  Связанные командлеты PowerShell: 
 Escape-символы — двойные \\, чтобы избежать их
Авторские права © 1999-2020 SS64.com 
 Некоторые права защищены.
 Многострочный комментарий в PowerShell — qaruQaruSite
 Переполнение стека
 Около
 Продукты
 Для команд
 Переполнение стека
 Общественные вопросы и ответы
 Переполнение стека для команд
 Где разработчики и технологи делятся частными знаниями с коллегами
 Вакансии
 Программирование и связанные с ним технические возможности карьерного роста
 Талант
 Нанимайте технических специалистов и создавайте свой бренд работодателя
 Реклама
 Обратитесь к разработчикам и технологам со всего мира
.
No related posts.