PowerShell — всё по этой теме для программистов

Оглавление (нажмите, чтобы открыть):

Изучение PowerShell — книги и ресурсы

Изучение PowerShell — книги и ресурсы

Данная статья открывает цикл записей, посвященных PowerShell. Да, пришло время командной строки!

Кратко — что такое PowerShell?

  • PowerShell — оболочка командной строки
  • команды PowerShell выполняются в конвейере
  • среда PowerShell может быть расширена, что позволяет применять различные технологии
  • и самое главное — освоив PowerShell, вы станете более квалифицированным администратором.

Почему PowerShell?

Стоит отметить два момента. В первую очередь — PowerShell действительно содержит язык сценариев; это очень компактный язык, в состав которого входит всего лишь порядка двух десятков ключевых слов. Но на самом деле PowerShell, как было сказано выше, — это оболочка командной строки, во многом сходная с cmd.exe или с оболочкой UNIX Bash.

Второй момент: Microsoft не поощряет практику использования оснащенных графическим интерфейсом консолей на серверах. Дело в том, что серверы могут обеспечивать эффективное функционирование графических интерфейсов лишь за счет ухудшения производительности сервера. Но использование графического интерфейса на клиентах, даже если эти клиенты подключены к серверу, вполне допускается и сегодня. Так в новых версиях Windows Server все функции доступны в первую очередь с помощью PowerShell и только потом (а некоторые и вовсе недоступны) с помощью графического интерфейса сервера.

Загрузить PowerShell можно с сайта TechNet — но в современных ОС MS Winodws он доступен «из коробки».

Для более легкого старта в изучении Windows PowerShell представляю вашему вниманию подборку различных материалов.

  • Русский блог команды разработки Powershell — blogs.technet.microsoft.com/powershell_ru
  • Блог команды разработки Active Directory Powershell — blogs.technet.microsoft.com/adpowershell_ru/
  • Документация с TechNet на русском — docs.microsoft.com/ru-ru/previous-versions/sql/sql-server-2008-r2/cc281945(v=sql.105)
  • Script Browser для Windows PowerShell ISE. Данное дополнение позволяет с легкостью отыскивать необходимые скрипты в TechNet Script Center по заданным критериям и параметрам. По мимо этого содержит специальный модуль Script Analyzer, который после анализа предлагает улучшения/изменения, повышающие эффективность написанного скрипта. Этот модуль можно получить в комплекте Windows PowerShell ISE которая является частью OC Windows. Загвоздка в том, что Windows Server и PowerShell ISE требуют активации. Лицензия сама по себе платная, но не стоит отчаиваться. У Вас будет порядка 180 дней что бы испытать данный продукт.
  • Dell PowerGUI — Позволяет упростить сборку собственных сценариев PowerShell до простого выбора необходимых командлетов, которые подходят для Вашей задачи, и перетаскивания их в нужные места. Идеально подходит для тех, кто являются новичком в работе с PowerShell, но имеете базовое понимание концепций. PowerGUI — простой в использовании редактор, который, вероятно, усовершенствует Ваше понимание сборки более сложных и усовершенствованных сценариев, особенно если Вы лучше всего усваиваете информацию визуально.

Один из самых основных источников знаний — прекрасная справка программы:

Надеюсь данный список ресурсов поможет Вам в изучении PowerShell. Какие книги и наработки использовали вы? Оставьте ответ в комментариях и удачи в освоении новых знаний! ��

Нашли ошибку в тексте? Выделите фрагмент текста и нажмите Ctrl+Enter

Разные cкрипты для Powershell

Оценка: 86.21 % — 14 Голосов

Общая

Буду хранить здесь разные говноскриптики для управления и получения информации из AD и прочих продуктов Microsoft.

Скрипты для Exchange

Выполнение данных скриптов происходит в Exchange Management Shell

Скрипт загрузки фотографий в учетные записи.

Фотографии должны быт 640х640 пикселей.

Скрипт берет файлы из папки с обработанными фотографиями.

param([Switch]$all,[Switch]$Hide,[Switch]$CheckOnly, [String]$UserNameSam)
$PhotoPath = «C:\UserPhotos\»
$ProceedPhotoPath = «C:\UserPhotos\Done\»
$OU = ‘Группа с пользователями в AD’
$UserPhotoCount = 0
$UserCount = 0
Function CheckPhoto($UserSamName_in, $UserPhotoFile_in)
<
$result = $false;
if (Test-Path $UserPhotoFile_in)
<
if( $Hide -eq $false) <
Write-Host «Найден:’$UserPhotoFile’ для $UserName($UserSam_in). » -ForegroundColor Green -NoNewline >
$result = $true
>
else
<
$result = $false
Write-Host «Не найден:$UserPhotoFile» -ForegroundColor Gray
>
return $result
>
Function SetPhoto($UserSamName_in, $UserPhotoFile_in)
<
$check_result = CheckPhoto $UserSamName_in $UserPhotoFile_in;
$result = $false
if($check_result -eq $true)
<
if($CheckOnly -eq $false)
<
$UserPhoto = ([Byte[]] $(Get-Content -Path $UserPhotoFile_in -Encoding Byte -ReadCount 0))
Set-UserPhoto -Identity $UserSamName_in -PictureData $UserPhoto -Confirm:$False
$result=$true
if( $Hide -eq $false) <
Write-Host «Загружен» -ForegroundColor Green >
>
else
<
if( $Hide -eq $false) <
Write-Host «Посчитан» -ForegroundColor Green >
>
>
return $result
>
Write-Host «ExchangePhotoUpload.ps1 [-all] [-check] [UserNameSam] [PhotoFile]»
$users = Get-User -OrganizationalUnit $OU
if ( $all -eq $true)
<
Write-Warning «## Загрузка фотографий для всех пользователей в OU=$OU из $PhotoPath»
foreach ($user in $users)
<
$UserName = $user.Name
$UserPhotoFile = $($PhotoPath+$UserName+».jpg»)
$UserCount++
if(SetPhoto $user.SamAccountName $UserPhotoFile)
<
$UserPhotoCount++
>
>
>
else
<
foreach ($user in $users)
<
if($UserNameSam -eq $user.SamAccountName)
<
$UserCount++
$UserName = $user.Name
Write-Warning «## Загрузка фотографии для $UserName в OU=$OU из $PhotoPath»
$UserPhotoFile = $($PhotoPath+$UserName+».jpg»)
#Write-Error «($UserPhotoFile)»
if(SetPhoto $user.SamAccountName $UserPhotoFile)
<
$UserPhotoCount++
>
>
>
if($CheckOnly -eq $true) <
Write-Host «Найдено:» -NoNewline >
else <
Write-Host «Загружено:» -NoNewline >
Write-Host » $UserPhotoCount фотографий для $UserCount пользователей»
>

Очистка логов Exchange

Что бы Exchange не толстел своими всевозможными логами.

Пути установки могут отличаться — проверь пути.

Set-Executionpolicy RemoteSigned
$days=0
$IISLogPath=»C:\inetpub\logs\LogFiles\»
$ExchangeLoggingPath=»C:\Program Files\Microsoft\Exchange Server\V15\Logging\»
$ETLLoggingPath=»C:\Program Files\Microsoft\Exchange Server\V15\Bin\Search\Ceres\Diagnostics\ETLTraces\»
$ETLLoggingPath2=»C:\Program Files\Microsoft\Exchange Server\V15\Bin\Search\Ceres\Diagnostics\Logs»
Function CleanLogfiles($TargetFolder)
<
if (Test-Path $TargetFolder) <
$Now = Get-Date
$LastWrite = $Now.AddDays(-$days)
$Files = Get-ChildItem $TargetFolder -Include *.log,*.blg, *.etl, *.txt -Recurse | Where <$_.LastWriteTime -le "$LastWrite">
foreach ($File in $Files)

>
Else <
Write-Host «The folder $TargetFolder doesn’t exist! Check the folder path!» -ForegroundColor «white»
>
>
CleanLogfiles($IISLogPath)
CleanLogfiles($ExchangeLoggingPath)
CleanLogfiles($ETLLoggingPath)
CleanLogfiles($ETLLoggingPath2)
gci -Path ‘C:\Program Files\Microsoft\Exchange Server\V15\Logging’,’C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\Logs’,’D:\iislog\’ -Include ‘*.log’,’*.blg’,’*.bak’ -Recurse -Force | ? LastWriteTime -lt (Get-Date).AddDays(-14) | Remove-Item -Recurse -Force

Для работы с Active Directory
Выгрузить список Пользователей с ПК

У каждого ПК в AD указан пользователь управляющий им. ПК пользователей выбираются по маске с определённой группы в 75 строке скрипта.

Данный скрип позволяет создать список пользователей с выгрузкой ФИО, должности, отдела, телефона, привязанных к ним ПК и прочего в CSV. И используется для автоматической постановки пользовательских ПК в систему мониторинга Icinga2.

function Write-Log
<
[CmdletBinding()]
Param
(
[Parameter(Mandatory=$true,
ValueFromPipelineByPropertyName=$true)]
[ValidateNotNullOrEmpty()]
[Alias(«LogContent»)]
[string]$Message,

[Parameter(Mandatory=$false)]
[Alias(‘LogPath’)]
[string]$Path=’C:\Temp\PowerShellLog.log’,

[Parameter(Mandatory=$false)]
[ValidateSet(«Error»,»Warn»,»Info»)]
[string]$Level=»Info»,

[Parameter(Mandatory=$false)]
[switch]$NoClobber
)
Begin
<
# Set VerbosePreference to Continue so that verbose messages are displayed.
$VerbosePreference = ‘Continue’
>
Process
<
# If the file already exists and NoClobber was specified, do not write to the log.
if ((Test-Path $Path) -AND $NoClobber) <
Write-Error «Log file $Path already exists, and you specified NoClobber. Either delete the file or specify a different name.»
Return
>
# If attempting to write to a log file in a folder/path that doesn’t exist create the file including the path.
elseif (!(Test-Path $Path)) <
Write-Verbose «Creating $Path.»
$NewLogFile = New-Item $Path -Force -ItemType File
>
else <
# Nothing to see here yet.
>
# Format Date for our Log File
$FormattedDate = Get-Date -Format «yyyy-MM-dd HH:mm:ss»
# Write message to error, warning, or verbose pipeline and specify $LevelText
switch ($Level) <
‘Error’ <
Write-Error $Message
$LevelText = ‘ERROR:’
>
‘Warn’ <
Write-Warning $Message
$LevelText = ‘WARNING:’
>
‘Info’ <
Write-Verbose $Message
$LevelText = ‘INFO:’
>
>
# Write log entry to $Path
«$FormattedDate $LevelText $Message» | Out-File -FilePath $Path -Append
>
End
<
>
>
$global:Path = ‘C:\Temp\MyLogFile.log’
$ComputerList = get-adcomputer -Filter <(Name -like "WS-*")>-SearchBase «OU=Рабочие станции,OU=Персональные компьютеры,DC=123,DC=ru» -properties Name,DNSHostName,Managedby | select Name,DNSHostName,@>,@Основы Windows PowerShell

В данной статье мы рассмотрим такую технологию от компании Microsoft как Windows PowerShell, мы поговорим о том, что такое PowerShell, что такое командлеты и конвейер, как писать сценарии и модули, а также затронем другие не менее важные и полезные возможности Windows PowerShell.

Что способствовало появлению Windows PowerShell?

До появления PowerShell существовали (и существуют) следующие инструменты для автоматизации и администрирования сервисов: командная строка Windows и Windows Script Host. Но у этих технологий есть недостатки.

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

Большинство программных продуктов имеет консольный интерфейс, т.е. мы можем управлять программой, используя командную строку, при этом экономя ресурсы за счет отсутствия затрат на работу графического интерфейса. Компания Microsoft для серверной операционной системы Windows Server даже выпускает редакции без графического интерфейса (Server Core, в Windows Server 2020 даже есть Nano Server), но всего этого недостаточно, так как возможности командной строки ограничены, т.е. написать какую-то сложную логику для автоматизации чего-либо мы не сможем, а если и сможем, то на это нам потребуется время и знания.

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

Технология Windows Script Host позволяет выполнять все административные задачи, что и командная строка, включая их автоматизацию путем написания WSH скриптов, но здесь мы уже можем использовать полноценные языки программирования (VBScript и JScript), т.е. можно реализовывать сложную логику и алгоритмы. К тому же с помощью WSH мы управляем программными продуктами через объектный интерфейс, другими словами Windows Script Host намного «круче» чем командная строка. Но данная технология также не стала тем идеальным инструментом администрирования и автоматизации этого администрирования для системных администраторов, так как Windows Script Host требовал знаний вышеперечисленных языков программирования, что для системных администраторов на самом деле лишнее. Администраторам нужно всего лишь простой инструмент администрирования с возможностью запрограммировать какие-то действия, а углубляться в объектные модели программных продуктов на языках программирования VBScript и JScript им не хочется.

В итоге компании Microsoft необходимо было разработать такой инструмент администрирования для системных администраторов, который бы на 100 процентов удовлетворял все потребности сисадминов как в плане возможностей администрирования и автоматизации, так и в плане удобства и простоты использования, таким образом, появился Windows PowerShell.

Что такое Windows PowerShell?

Windows PowerShell – это язык сценариев и командная оболочка Windows, которые разработаны для администрирования и конфигурирования операционных систем Windows. PowerShell разработан на основе среды CRL и платформы .NET Framework и в отличие от командной строки, которая принимает и возвращает текст, Windows PowerShell работает с объектами. У каждого объекта в PowerShell есть свойства и методы, которые можно использовать для управления этими объектами.

В Windows PowerShell Microsoft разработала концепцию командлетов (cmdlets), которая представляет собой систему именования команд «Глагол-Существительное». Данная система позволяет системным администраторам быстрей освоить и упростить работу с PowerShell.

С помощью Windows PowerShell можно:

  • Получать доступ к файловой системе;
  • Управлять реестром;
  • Управлять службами;
  • Управлять процессами;
  • Настраивать операционную систему;
  • Устанавливать программное обеспечение;
  • Устанавливать роли и компоненты сервера;
  • Осуществлять администрирование и конфигурирование ролей и компонентов сервера;
  • Писать и использовать сценарии для автоматизации управления и администрирования;
  • Выполнять другие задачи системных администраторов.

Windows PowerShell содержит многие часто используемые утилиты и команды, запускаемые из командной строки, например ipconfig, ping и другие. Сделано это для того, чтобы облегчить переход системных администраторов с командной строки на PowerShell.

Также для удобства многие часто используемые команды и утилиты в PowerShell имеют синонимы (Alias), например cls — это синоним командлета Clear-Host, dir синоним Get-ChildItem (полный список синонимов можно посмотреть путем запуска командлета Get-Alias).

Для упрощения поиска нужной команды в PowerShell есть специальный командлет Get-Command, с помощью которого можно осуществлять поиск, как по глаголу, так и по существительному. Все команды в Windows PowerShell сгруппированы в модули (например, Hyper-V, NetTCPIP), что также упрощает поиск нужной команды.

После того как нужная команда найдена, можно посмотреть инструкцию по работе с этой командой, т.е. справку, для этих целей есть специальный командлет Get-Help, например следующая команда покажет справку по командлету Get-Command:

Справка в Windows PowerShell может быть краткой, детальной (параметр -Detailed), полной (параметр -Full), а также можно выводить только примеры (параметр — Examples). Следующая команда покажет только примеры использования командлета Get-Command:

Справка PowerShell обновляемая, т.е. ее можно обновить командой Update-Help.

Версии Windows PowerShell

Первая версия PowerShell 1.0 появилась 14 ноября 2006 года и выпускалась в виде отдельного дистрибутива, который можно было установить на следующие версии операционных систем Windows: Windows XP Service Pack 2, Windows Server 2003 Service Pack 1 и Windows Vista.

В Windows Server 2008 PowerShell 1.0 поставлялся в виде компонента, который также нужно было устанавливать.

Начиная с Windows 7 и Windows Server 2008 R2, PowerShell поставляется как неотъемлемый компонент системы (т.е. предустановленный, устанавливать его не надо). Ниже представлена таблица соответствия версии PowerShell и версии операционной системы Windows (т.е. какая версия PowerShell по умолчанию установлена в той или иной версии Windows):

Версия PowerShell Версии Windows
PowerShell 2.0 Windows 7, Windows Server 2008 R2
PowerShell 3.0 Windows 8, Windows Server 2012
PowerShell 4.0 Windows 8.1, Windows Server 2012 R2
PowerShell 5.0 Windows 10, Windows Server 2020

С каждой новой версией PowerShell становится все более мощным инструментом администрирования, для сравнения в первой PowerShell было около 130 командлетов, а в PowerShell 5.0 их уже более 600!

Узнать текущую версию PowerShell можно с помощью свойства PSVersion встроенной переменной $PSVersionTable, например, выполните следующую команду:

Или запустите командлет

где, значение PSVersion и будет версией PowerShell.

Язык PowerShell

PowerShell – это объектно-ориентированный скриптовой язык программирования. Он используется для написания команд управления всеми компонентами операционной системы Windows в оболочке Windows PowerShell, а также для написания сценариев автоматизации задач администрирования в интегрированной среде сценариев Windows PowerShell (ISE). Язык PowerShell хоть и создан для задач администрирования, он является полноценным скриптовым языком программирования, так как имеет программные конструкции, которые присутствуют в каждом языке программирования, такие как: условия, циклы, обработка ошибок, работа с переменными, объектами, массивами.

Язык PowerShell имеет единый синтаксис написания команд и структуру именования этих команд по принципу «Глагол-Существительное», что делает данный язык интуитивно понятным как для программистов, так и для системных администраторов.

Более подробно о программировании на данном языке можете посмотреть в материале — Программирование на языке PowerShell.

Оболочка Windows PowerShell

Оболочка Windows PowerShell – это среда выполнения команд и сценариев на языке PowerShell. Данная оболочка имеет те же возможности что и командная строка такие как: хранение истории выполнения команд, настройка внешнего вида оболочки, завершение выполнения команд сочетанием клавиш Ctrl+C, а также много других возможностей, которых нет в оболочке командной строки, например такая замечательная возможность как «подсветка синтаксиса» (появилась в PowerShell 5.0).

Запустить оболочку PowerShell можно несколькими способами, например:

  • Из командной строки, набрав PowerShell;
  • Через диалоговое окно «Выполнить» (сочетание клавиш Win+R), также набрав PowerShell;
  • В Windows 7 — Пуск->Все программы ->Стандартные ->Windows PowerShell -> Windows PowerShell;
  • В Windows 8.1 или Windows Server 2012 R2 — Пуск->Все программы ->Служебные ->Windows PowerShell;
  • В Windows 10 или Windows Server 2020 — Пуск->Все программы -> Каталог Windows PowerShell (в группе W) -> Windows PowerShell.

Пример запуска PowerShell в Windows Server 2020

Скриншот оболочки PowerShell в Windows Server 2020

Командлеты в PowerShell

Командлет (cmdlet) – это команда Windows PowerShell, с помощью которой можно осуществлять взаимодействие с объектами операционной системы с целью их управления. Данные команды являются частью языка PowerShell. Командлеты построены по принципу «Глагол-Существительное», разделенные дефисом (-); другими словами, мы сначала указываем, что делать, а через дефис — над чем. Например, командлет Get-Help, где Get — это глагол, означающий «Получить», а Help — существительное «Помощь» в контексте PowerShell «Показать – Справку». Командлеты PowerShell возвращают результаты в виде объектов, что является одним из главных отличий от командной строки Windows, в которой команды возвращают только текст на экран.

Кроме командлетов на получение данных (Get), существуют и такие типы командлетов как:

  • Add – добавление данных;
  • Clear – очистить;
  • Enable – включить;
  • Disable – выключить;
  • New – создать;
  • Remove – удалить;
  • Set – задать;
  • Start — запустить;
  • Stop – остановить;
  • Export – экспортировать;
  • Import – импортировать;
  • И еще много других.

Полный список командлетов в Windows PowerShell можно посмотреть с помощью специального командлета Get-Command. Например, запустите его с параметром -CommandType cmdlet, в итоге на экране у Вас отобразится список командлетов.

Как Вы уже поняли, у командлетов есть параметры, с помощью которых мы можем конкретизировать действия командлета. Параметры бывают обязательные и необязательные, например, у командлета Get-Command обязательных параметров нет.

Ниже на картинке представлен способ поиска командлета по глаголу (параметр Verb). В данном случае у нас отобразился список командлетов, которые умеют что-то перезапускать.

Для поиска командлета по существительному необходимо использовать параметр Noun. Например, ниже мы получили список командлетов, которые работают со службами.

Если Вы не нашли нужный командлет по полному названию можете использовать маску в формате *Текст*.

Конвейер в PowerShell

Одной из главных возможностей Windows PowerShell является возможность использования конвейера при выполнении команд.

Конвейер – это передача результата работы командлета через вертикальную черту (|) другому командлету. При этом, как Вы помните, в PowerShell командлеты работают с объектами и возвращают объекты, соответственно по конвейеру передаются также объекты.

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

Например, давайте узнаем название самого большого файла в каталоге «C:\Windows\System32» (простой пример конвейера).

  • Get-ChildItem – командлет получения объектов в указанном каталоге;
  • Sort-Object – командлет для сортировки объектов, в нашем случае мы сортируем по размеру файла (length -Descending);
  • Select-Object – командлет выбора нужных свойств объекта, в нашем случае мы выводим стандартные поля и только самый первый объект, т.е. большой файл (параметр -First 1).

Все командлеты отделены друг от друга вертикальной чертой. Результат работы каждого командлета передается на вход другому командлету, т.е. сначала мы получаем все объекты в указанном каталоге, затем сортируем полученный результат и в заключение выбираем самый первый объект.

Фоновое исполнение заданий

В Windows PowerShell есть возможность фонового исполнения заданий, она представляет собой механизм, с помощью которого можно запустить на выполнение команду (например, которая долго выполняется) в фоновом режиме, т.е. после запуска Вы возвращаетесь в текущую сессию и можете продолжить работу, не дожидаясь окончания работы команды. Данная возможность Вам понадобится тогда, когда у Вас возникнет необходимость запустить команду, работа которой занимает достаточно продолжительное время, а как Вы знаете, в течение этого времени сессия оболочки PowerShell блокируется до завершения работы команды, а Вам нужно продолжать работать.

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

В Windows PowerShell для работы с фоновыми заданиями есть следующие командлеты:

  • Start-Job – запустить фоновую задачу;
  • Stop-Job – остановить фоновую задачу
  • Get-Job – посмотреть список фоновых задач;
  • Receive-Job – посмотреть результат выполнения фоновой задачи;
  • Remove-Job – удалить фоновую задачу;
  • Wait-Job – перевести фоновую задачу на передний план, для того чтобы дожидаться ее окончания.

Для запуска в фоновом режиме необходимо написать команду Start-Job, а в фигурных скобках <> команду или набор команд, которые необходимо выполнить в фоновом режиме.

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

Запуск задачи в фоновом режиме

Смотрим на список задач запущенных в фоновом режиме

Отображаем результат работы задания Job1

Как видим, у нас появилась задача со статусом «Completed», т.е. она уже выполнилась (просто Get-Service отрабатывает быстро).

Для того чтобы посмотреть результат работы фоновой задачи, т.е. командлета Get-Service, мы выполнили команду Receive-Job и передали ей имя задания (можно и значение идентификатора). В результате у нас отобразился список служб.

Удаленное управление на PowerShell

Windows PowerShell рассчитан не только на локальное использование, но и на удаленное выполнение команд. Данная возможность необходима, чтобы Вы могли со своего рабочего места управлять удаленными компьютерами, т.е. выполнять команды PowerShell.

Существует несколько способов удаленного управления:

  • С помощью параметра –ComputerName (есть у многих команд). Другими словами Вы передаете имя компьютера, на котором необходимо выполнить команду, в качестве параметра. Способ обладает недостатком, так как ограничивается выполнением одной команды;
  • С помощью сессий. Командлет Enter-PSSession (интерактивный сеанс). Таким способом Вы подключаетесь к удаленному компьютеру и все команды, которые Вы будете набирать в оболочке PowerShell, будут выполняться на удаленном компьютере так же, как если бы Вы набирали команды непосредственно на удаленном компьютере. Способ также обладает недостатком, так как сеанс ограничивается одним компьютером;
  • С помощью командлета Invoke-Command. С помощью данного способа можно выполнять команды или сценарии как на одном компьютере, так и на нескольких.

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

Сценарии, функции и модули в Windows PowerShell

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

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

Затем, для того чтобы выполнить этот сценарий, Вы просто запускаете его в оболочке PowerShell. При этом Вам необходимо либо указать полный путь к файлу сценария, либо перейти в каталог со сценарием и вызвать его по имени.

Важно!

По умолчанию выполнение сценариев в Windows запрещено! Для того чтобы посмотреть политику выполнения сценариев выполните командлет Get-ExecutionPolicy. В результате он вернет действующую политику, например:

  • Restricted – блокируется выполнение любых сценариев (значение по умолчанию);
  • AllSigned – разрешено выполнение сценариев, которые имеют цифровую подпись;
  • RemoteSigned – разрешено выполнение локальных сценариев, все скачанные сценарии должны иметь цифровую подпись;
  • Unrestricted — разрешено выполнение любых сценариев (не рекомендуется, так как небезопасно!).

Для разрешения выполнения сценариев необходимо использовать командлет Set-ExecutionPolicy с одним из вышеперечисленных параметров.

Например, для разрешения выполнения локальных сценариев выполним следующую команду, и согласимся с внесением изменений, нажав Y.

В сценарии можно передавать параметры, делать их обязательными или задавать значение по умолчанию.

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

Для этого необходимо указать ключевое слово Function и затем в фигурных скобках <> написать алгоритм работы этой функции, т.е. набор команд (например, какая-нибудь часто используемая процедура: создать пользователя с определенными правами, очистить определенные каталоги и так далее). Потом необходимо сохранить все это в сценарий, но только уже с расширением .psm1, так как этот файл будет являться уже модулем.

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

После того как Вы поместите написанный Вами модуль в специальный каталог, Вы сможете обращаться к своим функциям как к обычным командам PowerShell.

Интегрированная среда сценариев Windows PowerShell (ISE)

Для того чтобы было удобно писать сценарии, функции и соответственно модули, компания Microsoft разработала специальную графическую программу Integrated Scripting Environment (ISE) — интегрированная среда сценариев. Работать в этой программе очень удобно, к тому же она имеет мощный функционал (создание множества вкладок со сценариями, область вывода, встроенный отладчик и другое).

Запустить ее можно следующим образом:

  • В Windows 7 — Пуск->Все программы ->Стандартные ->Windows PowerShell -> Windows PowerShell ISE;
  • В Windows 10 или Windows Server 2020 — Пуск->Все программы -> Каталог Windows PowerShell (в группе W) -> Windows PowerShell ISE.

Примечание! ISE не будет работать на системе Windows Server, установленной в варианте Server Core.

Скриншот интегрированной среды сценариев PowerShell (ISE) в Windows Server 2020

На этом у меня все, надеюсь, материал был Вам полезен! Удачи!

Функции в Windows PowerShell

В предыдущей статье мы говорили о командлетах в Windows PowerShell. Теперь поговорим о следующем типе команд — функциях.

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

Создадим простейшую функцию Primer , которая просто выводит сообщение. Для этого введем в PowerShell

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

Функции способны работать с аргументами, которые передаются им при запуске. Сделать это можно с помощью переменной $Args , которая представляет собою массив с аргументами, или при помощи формальных параметров.

Изменим нашу функцию Primer , добавив в неё переменную $Args .

Тогда при вызове функции нам необходимо будет прописать аргумент или аргументы. Внимательно посмотрите на скриншот ниже.

Пример функции с аргументами в PowerShell

В данном случае «функции», «с» и «аргументами» — три элемента массива $Args . Как видим, они выводятся через пробел. Для того, чтобы убедиться, что это именно три отдельных элемента, введем разделитель в виде точки с помощью специальной переменной $OFS .

Использование переменной $OFS

Второй способ обработки аргументов функций в Windows PowerShell это использование формальных параметров. Формальные параметры указываются в круглых скобках после имени функции.

Продолжим наш пример с выводом сообщения. Снова изменим функцию Primer , приведя её к следующему виду

Результат будет тем же самым.

Использование формальных параметров

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

Создадим функцию Summa , которая складывала бы значения двух аргументов.

Мы можем задать значения параметров сразу. Если все значения уже заданы, функции не нужны дополнительные аргументы. Мы также вольны называть параметры по собственному усмотрению.

Видоизменим функцию Summa .

Мы обозначили параметры как $chislo1 и $chislo2 , задав им значения соответственно 15 и 20. Поскольку значения всех параметров здесь указаны, аргументы нам не нужны. Но, если мы всё-таки запустим эту функцию с дополнительным аргументом, то он заменит собой значение $chislo1 , а $chislo2 останется без изменений.

PowerShell также позволяет указывать тип параметра функции. Например, тип [int] это целые числа, [string] — текст, а [boolean] — логический тип данных.

Вот следующий пример.

Использование типов данных в Windows PowerShell

Как видим, в результате деления $a на $b должно было получиться 1,15. Но, поскольку мы указали интерпретатору воспринимать все параметры функции как целые числа, дробные значения были округлены до целых. Обратите внимание на округления, которые представлены ниже.

Они не совсем соответствуют тем законам математики, к которым мы привыкли.

Среди типов параметров есть так называемые «параметры-переключатели» обозначающиеся типом [Switch] . Их смысл состоит в логическом выборе, а сами параметры могут принимать только значения $True или $False .

Создадим функцию с таким переключателем.

В данном случае, если мы запустим функцию Vybor с параметром -a (аналогично, как мы запускали dir с параметрами -recurse и -filter в прошлой статье), то нам выйдет одно сообщение, а если без параметра, то другое.

Использование переключателя Switch в Windows PowerShell

На этом с функциями пока всё. Далее мы продолжим изучать типы команд в Windows PowerShell.

Приступаем к работе с PowerShell

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

Мастер Йода рекомендует:  Как создать по-летнему яркий, красочный сочный 3D - текст

Дон Джоунз (powershell@concentratedtech.com) — технический инструктор по PowerShell (www.windowsitpro.com/go/DonJonesPowerShell), имеет звание Microsoft MVP

— PowerShell — оболочка командной строки.

— Команды PowerShell выполняются в конвейере.

— Среда PowerShell может быть расширена, что позволяет применять различные технологии.

— Освоив PowerShell, вы станете более квалифицированным администратором.

Почему PowerShell?

Первым делом стоит развеять два важных мифа, касающиеся PowerShell. Миф первый: PowerShell — это язык сценариев. Неправда. PowerShell действительно содержит язык сценариев; это очень компактный язык, в состав которого входит всего лишь порядка двух десятков ключевых слов. Но на самом деле PowerShell — это оболочка командной строки, во многом сходная с cmd.exe или с оболочкой UNIX Bash. В этой оболочке выполняются команды — такие, как Ipconfig, Ping и другие команды, каковыми вы, несомненно, пользовались. Вполне возможно, на каком-то этапе у вас возникнет желание объединить несколько команд в пакетный файл, и вы имеете полное право назвать такой файл сценарием. Но составление подобных файлов нельзя считать программированием в том смысле, в котором программированием именуется разработка программ с помощью продуктов Microsoft Visual Studio.

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

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

PowerShell представляет всего лишь альтернативное решение для администраторов. Графические интерфейсы могут быть встроены таким образом, чтобы команды PowerShell выполнялись в фоновом режиме, так что PowerShell может, с одной стороны, играть роль функционального «движка» для графической оболочки, а с другой — служить инструментом, который администратор может использовать без применения дополнительных компонентов.

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

Выполнение команд

Не следует полагать, что работа с PowerShell всегда связана с трудностями. Представьте, к примеру, что вам нужно добавить в Active Directory (AD) учетную запись нового пользователя. Задача решается довольно просто:

New-ADUser -Name DonJ -samAccountName DonJ -Title CTO -City «Las Vegas» -Department IT

Как видите, команда New-ADUser принимает несколько параметров командной строки. Эти параметры (-Name, -Title, -City и т.д.) соответствуют полям, с которыми вам пришлось бы иметь дело в случае добавления пользователя с помощью оснастки Active Directory Users and Computers. Так почему же нам предлагается работать не с графическим интерфейсом, а с командной строкой? Потому что командная строка облегчает процесс решения нескольких задач в ходе одной операции.

Допустим, вы получили электронную таблицу Microsoft Excel со списком новых пользователей, которым требуются учетные записи. В первой строке этой электронной таблицы содержатся заголовки столбцов: City, Title, Department, Name и samAccountName — атрибуты этих пользователей. Сохраните данный файл Excel в виде файла значений с разделителями-запятыми (файл CSV). Можете назвать его NewUsers.csv. Теперь вы сможете задействовать PowerShell для создания новых пользователей:

Import-CSV NewUsers.csv | New-ADUser

Нетрудно убедиться, что таким образом задача решается намного быстрее, чем в случае создания пользователей средствами графического интерфейса. PowerShell дает возможность создать 100 пользовательских учетных записей всего лишь за несколько секунд, тогда как на формирование такого количества учетных записей с помощью графического интерфейса пользователя может уйти несколько часов. Кстати, New-ADUser — это команда из модуля Microsoft ActiveDirectory; ее можно найти в комплекте Remote Server Administration Tools for Windows 7, а также в контроллерах доменов Windows Server 2008 R2 (и более поздних). Для загрузки модуля в память (после установки его в системе) нужно будет выполнить команду

Изучаем синтаксис

Самая трудная задача в ходе освоения любого интерфейса командной строки, command-line interface (CLI), — это изучение синтаксиса команд. Какие параметры нужно использовать? Как каждый из этих параметров влияет на выполнение команды и какие значения он принимает? Нередко администраторы часами выискивают примеры использования синтаксических конструкций с помощью поисковых программ. Но в среде PowerShell подобные проблемы решаются гораздо проще. Вам нужно выполнить некую операцию с той или иной службой?

Выполните в оболочке эту команду, и вы получите список команд, применяемых к службам. Предположим, вы сочли, что вам, возможно, подойдет команда Set-Service. Вы можете быстро выяснить, как используется эта команда — для этого нужно запустить другую команду:

Здесь важен параметр -full. Этот параметр позволяет получить массу дополнительной информации, включая подробные инструкции по применению каждого параметра, а также практические примеры. Вам нет нужды искать примеры с помощью поисковой системы Bing; они уже заложены в продукт.

Отметим, что некоторые пользователи вместо короткой команды Help используют более строгий вариант Get-Help. Я предпочитаю первое; в этом случае после отображения каждого экрана текста автоматически вставляется пауза. Использование формата Help избавляет вас от необходимости неоднократно нажимать кнопку More для продолжения знакомства с синтаксисом команды.

Кое-что о «подводных камнях»

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

На экране появляется то, что выдала последняя команда конвейера. Если на выходе последней команды ничего нет, экран остается пустым. А теперь выполните команду в таком формате:

Команда Export-CSV не генерирует выходные данные, поэтому на экране ничего не отображается. Зато на диске появляется файл CSV, а это уже большое дело.

Кроме того, имейте в виду, что когда на экране все-таки появляется некий текст, его внешний вид определяется применяемыми по умолчанию настройками PowerShell. Эти настройки вы можете изменять:

Однако четыре команды категории Format — Format-List, Format-Table, Format-Wideи Format-Custom — не генерируют традиционные выходные данные. Они формируют инструкции, в соответствии с которыми будет форматироваться содержимое экрана. Следовательно, команда, подобная приведенной ниже, не будет функционировать так, как можно было бы ожидать:

В роли входных данных для команды ConvertTo-HTML выступают инструкции по компоновке экрана, поэтому мы получим файл HTML, состоящий из этих инструкций. Последние же по большей части состоят из шестнадцатеричных кодов и мусора; во всяком случае, такими они представляются пользователю. Но эту западню легко обойти: достаточно воздерживаться от использования каких-либо команд после команды Format. Исключение можно сделать для команд Out-Printer и Out-File; обе они созданы специально для того, чтобы помочь пользователю разобраться в инструкциях по компоновке экрана.

Расширение оболочки

Подобно консоли управления Microsoft Management Console (MMC), оболочка PowerShell предусматривает возможность расширения, что позволяет применять в ней различные технологии. Как следует из таблицы, расширить оболочку можно двумя способами; выбор зависит от того, используете вы PowerShell версии 1 (v1) или версии 2 (v2). Оба метода обеспечивают возможность определять, какие расширения установлены в системе локально.

Следует отметить, что метод поиска PowerShell v2 отыскивает лишь модули, установленные там, где им положено находиться; между тем, некоторые расширения продуктов размещают свои модули, скажем так, в неположенных местах. Однако эти продукты обычно создают ярлыки меню Start, которые указывают пользователю на место установки соответствующего модуля.

Некоторым пользователям досадно, что созданы некие версии PowerShell, предназначенные для взаимодействия с определенным продуктом, такие, как Exchange Management Shell или SharePoint Management Shell. На самом же деле никаких «особых» версий, ориентированных на взаимодействие с другими пакетами, не существует. Просто разработчики Microsoft дали некоторым функциям PowerShell имена, наталкивающие на ошибочный вывод. Пример — Exchange Management Shell. Это не более чем экранный ярлык меню Start. Просмотрите его свойства, и вы увидите, что данный ярлык всего лишь запускает на выполнение всем известный файл PowerShell.exe. Точнее говоря, он одновременно запускает программу PowerShell и выполняет в автоматическом режиме тот или иной сценарий либо загружает тот или иной модуль. Соответствующий модуль вы можете загрузить вручную. Загляните в свойства рассматриваемого ярлыка меню Start, определите, где расположен интересующий вас модуль, и запустите команду

Таким образом, вы сможете загрузить в оболочку хоть все имеющиеся модули.

Объекты

Специалисты отрасли так много говорят об объектах в среде PowerShell, что некоторых это просто выводит из себя. Им тут же приходят в голову такие, скажем, мысли: «Это уже похоже на разработку, а я программистом не нанимался. Так что давайте как-нибудь без меня!».

Успокойтесь, коллеги. «Объект» — это всего лишь слово, и означает оно «структура данных». Представьте себе электронную таблицу Excel или даже таблицу базы данных Microsoft Access. Каждая строка в таблице или в электронной таблице представляет собой объект, а каждый столбец — свойство. Вот и все, ничего сложного. Команда

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

Например, удалять объекты, на которые вы не хотите смотреть. Или, используя команду Where-Object в качестве фильтра, убирать из конвейера те или иные элементы. Рассмотрим для примера такую команду:

Она отображает список служб — но только тех, что выполняются в данный момент. Синтаксис запутанный, однако он поддается анализу. Внутри фигурных скобок (где перечисляются критерии объектов, которые вы хотите увидеть) содержится комбинация символов $_; это выходные данные предыдущей команды. Я не хотел просматривать весь объект service; мне нужно было поработать только с частью этого объекта. А как мы обозначаем часть или дробь в математике? Точкой, отделяющей дробь от целого (как в выражении «3.147», верно? Поэтому я поставил после символов $_ такую точку, а затем указал дробь, с которой мне нужно было поработать: Status. Из предшествующего опыта работы с командой Get-Service мне известно, что если в ячейке столбца Status указывается значение Running, речь идет о выполняемых в данный момент службах. Поэтому я указал, что мне требуются лишь те службы, значение которых, заданное в столбце Status, равно (equals, или с использованием оператора сравнения -eq) Running. Если вы хотите получить об операторах сравнения более подробную информацию, выполните команду

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

Изменяйте порядок сортировки. По умолчанию сортировка всегда осуществляется в порядке возрастания. При необходимости измените порядок на обратный:

Комбинируйте. В качестве входных данных для одной команды вы можете использовать выходные данные многих других команд:

Интернет — не последняя инстанция

Одна из проблем, связанных с Интернетом, состоит в том, что право голоса в Сети может получить любой человек. Разработчики среды PowerShell позаботились о том, чтобы она была доступна самым разным категориям пользователей. И если вы обнаружили образец сценария объемом около 900 строк кода, из этого отнюдь не следует, что подобный «программистский» подход составляет единственный способ применения PowerShell. Данный сценарий показывает лишь, каким образом один из многих пользователей решил применить этот продукт — возможно, кстати, потому, что данный подход понятен этому человеку лучше всех прочих.

На сайте http://ShellHub.com я представил краткий перечень ресурсов PowerShell, авторы которых отстаивают не «программистский» подход, а более органичный для администраторов подход, предполагающий введение команды с клавиатуры с последующим нажатием клавиши ввода. Со временем вы наверняка начнете модифицировать свой метод работы, и он будет становиться все более сложным. И это замечательно. Но вы можете начать с простых вещей и добиваться превосходных результатов. Приведу такой пример. В книге Windows PowerShell Scripting and Toolmaking я начинаю с разъяснения простой команды, которую вы можете ввести с клавиатуры и немедленно получить результат. Постепенно я раскрываю все возможности этой команды: ввожу дополнительные параметры, привлекаю справочные материалы и т.д. — и наконец, одолев еще 100 страниц печатного текста, читатель воспринимает рассматриваемую команду как собственную команду PowerShell. Нет никакой нужды использовать оболочку PowerShell сразу во всей ее сложности. Начните с самого простого и постепенно беритесь за все более сложные задачи.

Не нужно начинать все с начала

На занятиях, посвященных среде PowerShell, я часто задаю своим студентам вопрос: «Как в PowerShell подключается сетевой диск?». В попытке найти ответ на этот вопрос многие обращаются к справочной системе. В ходе поисков студенты часто останавливают свой выбор на New-PSDrive, что, кстати, не является правильным ответом; эти накопители не видны за пределами PowerShell. В конце концов я объявляю им правильный ответ: Net Use.

Присутствующим остается лишь сокрушаться: «Ну почему это не пришло мне в голову?». Что ж, студенты получили хороший урок: Microsoft не предлагает нам забыть все, что мы уже знаем. Странно, правда? Все известные нам по окну командной строки приемы — Net Use, Icacls, DsAcls, NSLookup, Ping, Ipconfig, Pathping — по-прежнему функционируют, так что продолжайте с ними работать. Более того, эти средства можно свободно использовать совместно с собственными командами PowerShell. Так что если вы уже знаете, как решается та или иная задача, не ломайте голову над тем, как это делается в среде PowerShell. Смело применяйте известные вам приемы.

Почему некоторые администраторы не решаются приступать к изучению PowerShell?

Я открою вам маленький секрет. Многие администраторы стали администраторами Windows (а не администраторами UNIX или других систем) потому, что с Windows работать проще, по крайней мере, на первый взгляд. Запустите парочку мастеров, нажмите две-три кнопки — и ваша работа сделана. Многие из таких администраторов, в сущности, очень слабо представляют, какие именно процессы скрывают от нас эти кнопки и мастера. Вот почему перспектива освоения PowerShell пугает их. Дело не в том, что таким администраторам страшно браться за изучение синтаксиса, и не в том, что они считают нудным делом ввод данных с клавиатуры. А дело в том, что, работая с графическим интерфейсом, эти администраторы привыкли, что их, что называется, буквально «водят за ручку», тогда как PowerShell явно нарушает эту традицию.

Умение эффективно работать с PowerShell предполагает четкое понимание процессов, протекающих в системах, которыми вы управляете. Навыки применения PowerShell — признак первоклассного, знающего администратора. К сожалению, за годы, когда внутренние механизмы системы были скрыты от нас графическим интерфейсом, многие из наших коллег утратили часть знаний, которыми они должны владеть. Мне приходилось беседовать с администраторами, которые никогда не пользовались утилитой проверки связи Ping, которые без оснащенного графическим интерфейсом инструмента не могут отыскать причины неполадок в механизме репликации AD и которые имеют весьма слабое представление о том, как почтовые сообщения выстраиваются в очередь и доставляются в системе Exchange. Таким администраторам трудно овладеть навыками работы с PowerShell.

А вот вопрос для вас, уважаемые читатели. Скажите, можете ли вы создать пользовательскую учетную запись AD с незаполненным именем входа? Ответ: да, но только одну. Разумеется, применивший эту учетную запись пользователь не сможет зарегистрироваться в системе, но, с другой стороны, единственное требование к имени входа со стороны AD состоит в том, чтобы это имя было уникальным. Незаполненное имя уникально в первый раз, когда вы его используете; и только попытка создать второго пользователя с незаполненным именем приведет к сбою. Разумеется, если вам доводилось обращаться к AD только через графическую консоль, вам это обстоятельство неизвестно, поскольку графическая консоль вообще не принимает «незаполненных» имен. Но если внутренние механизмы AD известны вам досконально, ответ будет вполне очевиден.

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

Учитесь — или ищите другую работу

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

На эту ситуацию можно взглянуть и под другим углом. Если вы ценны для своей компании только тем, что способны нажимать на кнопки Next, Next, Finish и при этом не понимаете, что происходит «под капотом» и как можно автоматизировать задачу, чтобы она выполнялась быстрее и эффективнее. Ну, тогда вы относитесь к той категории работников, которых я называю «обезьяна у кнопки». Иными словами, заменить вас можно, что называется, в два счета. Что касается меня, я предпочитаю быть специалистом, обладающим доступными только для посвященных знаниями о том, как автоматизировать работу. Это избавляет меня от необходимости выполнять скучные повторяющиеся операции. А, кроме того, такого сотрудника будет не так-то просто уволить.

Поделитесь материалом с коллегами и друзьями

Вадим Стеркин

PowerShell 5.0 идет с Windows 10, но для предыдущих ОС новая версия вышла в составе Windows Management Framework 5.0 только в конце февраля, причем со второй попытки. Сегодня я расскажу о некоторых нововведениях, но начну с того, зачем вам может понадобиться PowerShell.

@0utsidethebox @vsterkin а зачем к нему приобщаться, в чем преимущества его использования? Вообще хотел бы статью о том на хрена он вообще

Зачем вам нужен PowerShell

Просто так изучать PowerShell нет смысла, и это верно для любого языка – скриптового, программного и даже человеческого. Как и многие решения Microsoft, PowerShell делается с прицелом на бизнес для автоматизации задач по управлению ПК и серверами в организациях.

Ключевое слово здесь автоматизация. Если у вас некая рутинная задача, которую вы хотите автоматизировать, попробуйте выяснить, можно ли это сделать с PowerShell.

В основе скриптового языка лежит мощная программная платформа .NET, поэтому возможности PowerShell простираются намного дальше администрирования.

Как-то раз мне понадобилось удалить один столбец из множества книг Excel 2013. Ручная работа претила, а гугление не давало готового решения. Я создал тему на форуме (да, я тоже иногда задаю вопросы на OSZone :). Мне подходил любой язык, но решение неожиданно для меня оказалось на PowerShell. Как выяснилось, можно загрузить Excel в качестве COM-объекта и манипулировать им дальше.

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

Думаю, идея понятна, и можно уже переходить к новинкам PowerShell 5.0.

[+] 8 полезных возможностей

Подсветка синтаксиса

В новой консоли намного легче ориентироваться!

Красный цвет и нумерация строк, однако, из другой оперы.

Поиск по истории в двух направлениях

Сочетания клавиш: Ctrl + R и Ctrl + S
Командлеты: Get-PSReadlineKeyHandler и Set-PSReadlineKeyHandler

Как и в CMD, в PowerShell есть история сессии с навигацией стрелками, a Get-History выводит журнал по аналогии с F7 . Полный список сочетаний клавиш, связанных с журналом, можно вывести так:

В результатах появились две новые функции поиска по истории, которые показаны на картинке ниже. Работает это очень просто.

  1. Нажмите сочетание Ctrl + R и начните вводить запрос → появится последний найденный результат.
    Увеличить рисунок
  2. Повторите сочетание Ctrl + R , чтобы увидеть предыдущее совпадение, или измените запрос.

В отличие от Get-History, содержащей историю текущей сессии, этот журнал ведется глобально и сохраняется при закрытии окна.

Спасибо за наводку Антону Дровосекову и Константину Сидякину из нашей группы ВК.

Создание соединений, символических и жестких ссылок

Командлеты: New-Item, Remove-Item, Get-ChildItem

У меня в блоге хватает рассказов про ссылки NTFS, поэтому я не мог обойти вниманием возможность их создания в PowerShell.

Честно говоря, синтаксис команды mklink запомнить проще, поэтому быстрее может получиться так:

Создание временного файла

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

При создании CheckBootSpeed у меня была именно такая задача – записать собранные данные во временный файл, показать его в блокноте и удалить. Командлета не было, но Василий Гусев подсказал такой вариант:

Здесь обратный случай – командлет легче запомнить, чем класс .NET. В утилите я сейчас такой способ не использую, но на заметку взял.

Очистка корзины

Для очистки корзины сделали новый командлет, который пригодится администраторам в рутинных скриптах по обслуживанию ПК.

Создание и распаковка архивов

Командлеты: Compress-Archive и Expand-Archive

Архивация файлов в ZIP – очень распространенная задача, и я не понимаю, почему Microsoft так долго тянула с простой реализацией в PowerShell.

Копирование файлов между сессиями

Новая возможность командлета copy упрощает администраторам вполне типовую задачу копирования файлов на удаленный ПК. На целевой машине должна работать служба удаленного управления WinRM, которая конфигурируется одной командой:

Для подключения к машине в доверенном домене больше ничего не требуется. В рабочей группе надо на своем ПК добавить целевой компьютер в доверенные узлы по имени ПК или IP-адресу:

Дальше вы создаете новую сессию, указывая имя пользователя для подключения к удаленному ПК, и вводите учетные данные. В созданную сессию можно копировать файлы.

Полезное дополнение к возможностям удаленного управления PowerShell, согласитесь.

Ссылки по теме PowerShell Remoting:

  • Основы настройки и удаленного управления (Хабр)
  • Выполнение удаленных команд (TechNet)

Управление пакетами (автоустановка программ)

В Windows 10 встроено управление поставщиками пакетов (оно же OneGet), с помощью которого вы можете загрузить и тихо установить сразу несколько приложений одной командой! Это похоже на Apt-Get в Linux, но можно провести и параллели с Ninite или InstallPack (кто-нибудь пользуется?)

Увеличить рисунок
Архитектура управления пакетами

Я редко делаю чистую установку основной системы, но на ВМ это происходит регулярно. И OneGet очень удобен для быстрой автоустановки ключевого набора программ.

Примечание. Можно использовать этот модуль, не устанавливая WMF 5.0. Предварительная версия модуля для PS 4.0 и 3.0 доступна отдельно — март 2020 тут, а более свежие ищите поиском в центре загрузки по запросу PackageManagement PowerShell Modules Preview.

Установка программ

В этом примере из репозитория Chocolatey устанавливаются четыре программы и полный набор утилит Sysinternals. Первые три команды выполняются однократно, причем смену политики надо подтвердить. Четвертая команда тихо устанавливает перечисленные программы, а пятая просто экономит время.

Поставщик скачивает в C:\Chocolatey\lib пакет, в основе которого лежит скрипт chocolateyInstall.ps1. Он загружает установщик программы с официального сайта в папку %temp%\Chocolatey и запускает его в режиме тихой установки. Простейший пример – Notepad++.

Поиск программ

В репозиториях много программ, все самые популярные точно есть.

Удаление программ

С удалением приложений не все так гладко, впрочем.

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

Ссылки по теме OneGet и тихой установки:

  • Пошаговое руководство по установке программ из PowerShell (Дмитрий Буланов)
  • Командлеты управления пакетами (TechNet)
  • Типы инсталляторов и ключи тихой установки (моя статья 2005 года вполне актуальна 🙂
  • Сайт автоустановки Windows и форум автоустановки программ

Дискуссия и опрос

Для опытных «скриптовиков» и системных администраторов в PowerShell 5.0 есть и другие интересные возможности (например, классы по аналогии с языками объектно-ориентированного программирования). Полный список вы найдете на этой странице TechNet (ссылка ведет на английскую версию специально, поскольку русская пока не содержит сведений о 5.0).

В комментариях расскажите, как вы проголосовали в опросе, если вы не выбрали первый пункт (тут все ясно). Особенно интересуют подробности тех, кто использует скрипты, а также не нашедших своего варианта.

Как вы устанавливаете программы после чистой установки системы?

  • Вручную устанавливаю свежие версии (73%, голосов: 235)

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

Об авторе

Вадим является владельцем этого блога, и большинство записей здесь вышло из-под его пера. Подробности о блоге и авторе здесь.

Вас также может заинтересовать:

Подпишитесь на бесплатные уведомления о новых записях и получите в подарок мою книгу об ускорении загрузки Windows!

комментариев 100

Подсветка синтаксиса в PowerShell 5.0, это установленный по умолчанию модуль PSReadLine. В предыдущих версиях его можно доустановить и прописать его в загрузку в профильном скрипте (переменная $profile) или подгрузить самому, когда нужно

Он же не входит в поставку предыдущих ОС. Расскажите, откуда установить тогда уж.

Откуда брал раньше, я не помню. Сейчас (в 5 версии) модули можно брать из специального репозитария. Выбираем нужный модуль на http://www.powershellgallery.com/PSModule
Сохраняем его или сразу устанавливаем (прямо из консоли):

Можно поподробнее про тихую установку из скриптов? Не так давно стал пользоваться chocolatey, очень нравится, особенно обновление всех программ одной командой. Пока не разобрался с тихой установкой, все ставлю в ручном режиме, команда-подтверждение-установка.

Александр, да вроде все программы в chocolatey ставятся тихо. Вы же можете посмотреть команду на установку, пример в статье, равно как теперь и ссылка на типы инсталляторов и ключи тихой установки.

единственное, для чего пока мне понадобился PowerShell в win 10, это обход бага с неработающей кнопкой «свойства» в настройках VPN соединения. Set-VpnConnection -Name «Name» -SplitTunneling $true.
Кстати, Вадим. Есть какая-либо информация по этому поводу? Речь идет о кнопке в свойствах VPN соединения — сеть — IP версии 4 — «свойства». там обычно можно убрать галку «использовать шлюз в удаленной сети». сама кнопка активна, но при нажатии ничего не происходит. тут и помог PowerShell.

Я уверен, что в приложении Feedback там куча плюсов, добавьте свой.

Огромное спасибо за Chocolatey
на windows 7 я так понял на работает?

Сергей, надо установить WMF 5.0 — это первая ссылка в статье.

Да вроде и без него заработало. А можно что бы он еще создавал ярлыки определенных программ на рабочем столе?
Давно так хотел найти что то подобное… Так надоело все вручную делать) дрова бы он еще сам ставил

Сергей, вы посмотрите сайт автоустановки — там все есть: Создание ярлыков при установке ОС

По голосованию… Использую почти все варианты. Часть программ в портативном виде. Часть — устанавливается ручками с диска, для тех, которые умеют сами обновлятся или серьезная доработка давно закончена. Из них, часть скриптом. Часть новыми. Часть уже предустановлена в образ.
Опять же, клиенты и задачи бывают разные.

Про PowerShell… Считаю, что Микрософт промахнулся с названием. С первого взгляда, непонятно что получилось. Командная оболочка/процессор или скриптовый язык программирования. Слово Shell наталкивает на первое, но тогда уже давно пора, раз она такая крутая, сделать ее по умолчанию или хотя бы продвигать ее в качестве основной. Но реальные юзкейсы больше наталкивают на второе, замену WSH.

Lecron: но тогда уже давно пора, раз она такая крутая, сделать ее по умолчанию или хотя бы продвигать ее в качестве основной. »

В Win+X можно заменить CMD на PS (свойства панели задач — навигация). И продвигают они в качестве основной давно — на TechNet уже давно ничего нового нет про CMD, только PS.

Конечно, целевая аудитория — ИТ-специалисты, но то же самое можно сказать про CMD и WSH. Но я не вижу вреда для ЦА своего блога. Я нахожу применение PS дома и на работе, и это не связано с администрированием..

Я не про вред. А про непонимание и соответствующие ошибки.
Что это такое? Чем его видит Микрософт? Командный процессор, работающий, как правило, в интерактивном режиме, который также может читать команды из файла, который называется скриптом? Или как язык написания скриптов, у которого есть свой REPL? Согласитесь, разница большая?

Работать интерактивно в одном синтаксисе и семантике, а писать последовательности действий в других — нелепо. В этом и есть основная проблема. Такая глубинная, что даже вы ее не замечаете, хотя косвенно упомянули в статье. Синтаксис mklink не проще, а привычнее. Так как New-Item, с единым синтаксисом, позволяет создавать очень очень многое. И вот уже, фактически, его синтаксис проще, чем знание многих отдельных утилит, включая их наименование.

Обещание сдержали — вот вам модуль для управления менеджерами пакетов, вперед.

Не понял. Что такое «модуль управления менеджерами»?

Я оговорился, модуль управления поставщиками пакетов. Кликабельно.

Мне кажется, тут то собака и порылась. В провайдерах. Когда нет единого подхода к управлению пакетами. Фактически пользователю приходится знать и учитывать, какой из провайдеров используется. И не только пользователям, но и мейнтенерам.

Фича, как обычно, ориентирована на организации, а MSI и MSU поддерживаются в полный рост.

Возможно я не понял всей глубины этой фичи, поэтому такие глупые претензии.
Понадобятся ли пользователю дополнительные телодвижения, если владелец репозитория/пакета сменит провайдера? Или создатель пакета изменит его настройки? Или все это берет на себя менеджер пакетов?

Гм… вот фича — возьмите, попробуйте, разберитесь — это поможет снять некоторые вопросы. Есть поставщик, у него есть пакеты в репозитории. Убрали конкретный пакет? Тогда вы не сможете его скачать у этого поставщика. Но уже скачанный пакет остается локально, им дальше можно управлять.

Мастер Йода рекомендует:  Инструменты адаптивного дизайна нового поколения Webflow, Edge Reflow, Macaw

Кстати, вот еще вопрос. А есть ли команда Update-Package, а еще лучше Update-AllPackage?

Все командлеты перечислены на TechNet, ссылка в соотв. разделе статьи…

Привет. Скажи можно ли восстановить boot или bios и как это сделать? Слетел загрузчик виндовс 7 про. В boot изменил уже настройки но винда не хочет загружатся. Ранее была представлена винда 8.1 в сервисе воткнули винду 7 про без моего согласия. Помоги решить проблему!

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

поставил массово набор софта уже стоящий на пк. только около 70% нашлось в репозитории.
ключи —y —accept-license —f —x — маны покурил буквально пару минут, может что не понял.
итог:
софт который я не просил: autoIT, autohotkey. зачем?
накатило старую версию Acrobat Reader DC, cheat engine;
не смогло скачать dropbox virtualbox;
тихий режим не сработал viber, wireshark, light alloy — пришлось ставить галочки и жмакать далее;
skype удалило старый, но не поставило новый.
и часть ярлыков не создала, теперь нужно вспоминать какие.

Warnings:
— adobereader
— windjview
— firefox
— notepadplusplus
— teamviewer

тут я не понял что за ошибки.

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

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

AutoIT и AHK ставят для тихой установки других программ.

понимаю, что автор сам должен подсуетить и обновить свой продукт везде где можно, но меня, как юзера, должен заботить только итог.
можно ли делать фидбек на обновление\ошибки через шоколадку, я не разобрался. пинать всех авторов лично — муторно и часто бесполезно. продукты они хорошие делают, но сами очень неповоротливые.

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

на тестировании win10, MS кстати громко обещали что сделают свой менеджер пакетов и тд и тп. но чую они опять на магазине успокоились. да и много чего они обещали, все пускаю слезу на свою люмию.

Алексей: на тестировании win10, MS кстати громко обещали что сделают свой менеджер пакетов и тд и тп. но чую они опять на магазине успокоились.
»

Обещание сдержали — вот вам модуль для управления менеджерами поставщиками пакетов, вперед. Они не обещали свой репозиторий поддерживать.

Буквально сегодня натолкнулся на Хабрахабре в первый раз на упоминание Chocolatey и тут же в Вашей рассылке. Показалось что вот оно! Думал будет потрясающая скриптовая замена автоустановке свободнораспространяемого ПО с ninite.com, но увы. Актуальность софта не поддерживается на паранаидальном уровне, и проблематика есть описанная участниками выше.

Сергей, тут минорная разница. Предполагаю, что нет прямой ссылки на загрузку новой версии, приходится каждый раз править пакет, следить. Разработчик ПО не помогает никак репозиторию.

А созданы ли разработчику условия для такой помощи. Хотя бы не условия, а предпосылки. Мол это теперь проще, быстрее, удобнее, автоматизированнее. Посмотрите %сюда% и оцените плюшки.

Разработчику выгодно чтобы его приложение было всегда самой актуальной версии, поэтому я не понимаю претензий что неудобно пользоваться стандартными средствами дистрибьюции

Логично. Однако… как в комиксе xkcd про очередной стандарт. Отказаться от встроенной в программу системы поддержки актуальности не получится, так как виндовая распространена слабо, а поддерживать две накладно. Тем более, что виндовая, судя по комментариям, пока больше похоже на альфа-тест. То то не так, то это не эдак.
Поэтому и говорю про условия и предпослыки. Это должно быть не просто легко и удобно, а очень легко и удобно. Надеюсь, в ближайшем будущем доработают до вменяемого состояния, вместо выяснения необходимости в кнопке Пуск. 🙂

Я считаю, что для консоли лучше подходит философия UNIX:

Пишите программы, которые делают что-то одно и делают это хорошо.
Пишите программы, которые бы работали вместе.
Пишите программы, которые бы поддерживали текстовые потоки, поскольку это универсальный интерфейс.

Вот например, зачем запихивать в PS «Создание соединений, символических и жестких ссылок» со своим синтаксисом, если есть mklink? Для чего там «Создание и распаковка архивов», если есть zip и его аналоги?

Виталий, а что, в Windows входит консольная утилита для ZIP? А делается это для упрощения скриптов на PowerShell, не надо лезть в CMD, интегрированная справка и т.д.

А зачем лезть в cmd, если и тот и другой shell, и оба должны самостоятельно запускать исполняемые файлы и управлять их вводом выводом?
Против включения такого функционала не возражаю, особенно если это сделано по уму, как интерфейс к zlib, а не очередное разбухание кодовой базы — в проводнике одно, в шелле другое, в cmd третье стороннее.

очередное разбухание кодовой базы

Мое мнение, что PowerShell, это переходный инструмент администрирования прежде всего в корпоративном сегменте. Причем переход не от батников, а от WSH. Поэтому на локальных машинах будет жить cmd.exe с тонной обвесов в виде различных утилит (ведь всем известно, что без некоторых жизни нет), а на другом уровне администрирования применяется более сложный и несравнимо мощный инструмент.

Что касается личного ноутбука, то за собой замечаю, что все гнутые sed’ы и grep’ы пылятся без дела и даже wget почти не используется.

Нет, не входит.
Но я и на своём хостинге при первой попытке использовать zip получил что- то типа «zip не установлен. Установите командой apt-get install zip».

Лезть в cmd? Выше сказали, что PS должен запускать бинарники.

Справка? В Linux команда man %имя_утилиты% либо %имя_утилиты% -?, первая даёт подробный мануал, вторая как краткая справка по параметрам. Работает кажется везде.

В итоге командный интерпретатор на Linux- одновременно простая и мощная вещь, есть множество альтернатив, так как в нём самом нет ничего сложного, он просто запускает программы, управляет потоком вывода и интерпретирует простейший синтаксис.

Виталий, что вы предлагаете конкретно? Не развивать OneGet в частности или PowerShell вообще и перейти на Linux?
Есть пожелания по развитию? Подпишитесь на @PSOneGet, доставляйте фидбэк в юзергруппу.

Лично я хочу понимания, что это shell или repl. В том числе от евангелистов и разработчиков. С соответствующим отношением к творению. Ведь отсюда все споры и ошибки продвижения.
В частности, ответа на вопрос, зачем shell-у, своими средствами работать с архивами. Представьте, что этому научили cmd. Какие эмоции это у вас вызовет? И почему они отличаются от текущих?

ЗЫ. Считаю, что shell-ом, на чье звание он претендует, станет тогда, когда его можно будет безболезненно прописать в ComSpec.

PowerShell развивать в другом направлении. Хотя наверное уже поздно и проще переписать с нуля.

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

Я не имею твиттера.

Официальный репозиторий не помешал бы, но я не очень верю в его рождение. Может быть, с появлением приложений Win32 в магазине это как-то и увяжут с OneGet: магазин будет поставщиком, условно говоря. Посмотрим…

Vadim Sterkin: Виталий, а что, в Windows входит консольная утилита для ZIP? »

Стесняюсь спросить: а не проще было её добавить, чем запиливать встроенный функционал?

Что значит «не проще»? Вы развернули чистую ОС в изолированной среде — откуда вы будете ее добавлять? Встроено в оболочку сто лет как, между тем.

ПШ пишет МС, и дистрибутивы собирает МС, не проще было в дистрибутив добавить консольный зип?

PS пишет одна команда, консольный зип не пишет другая команда, поэтому нет, не проще. И нет, не проще.

Забавно, обычно базар ставят в недостатки опенсорс-(в частности линукс)-сообщества, а на деле МСовский собор как лебедь, рак и щука.

> зачем shell-у, своими средствами работать с архивами

Если есть такая возможность, заложенная в .Net-классах, то почему бы ее не использовать? Тут просто другой подход, отличный от bash или cmd, которые интерпретаторы командной строки. CLI. А PowerShell скорее отладчик для скриптов, имхо.

Буквально вчера опубликовал статью как я накатываю приложения на свежую систему https://habrahabr.ru/post/278757/

LecronЧто это такое? Чем его видит Микрософт? Командный процессор, работающий, как правило, в интерактивном режиме, который также может читать команды из файла, который называется скриптом? Или как язык написания скриптов, у которого есть свой REPL? Согласитесь, разница большая?»

Понятно, что задачи разные. Но я не вижу между ними противоречия. Т.е. вполне возможно одним инструментом закрыть обе потребности. К этому и стремится PowerShell. Что-то получается удачно, что-то не очень. Но виденье понятно.

Vadim Sterkin:
И продвигают они в качестве основной давно — на TechNet уже давно ничего нового нет про CMD, только PS.
»

Скоро будет, надо полагать. CMD (саму оболочку) сейчас сравнительно активно начали дорабатывать. Хотя до этого лет десять не трогали вообще.

Вы не путаете консоль conhost и командный интерпретатор cmd?
Ведь powerShell также запускается в conhost.

PowerShell не обязательно запускается в conhost. Из стандартных — есть ещё ISE. А есть ещё сторонние хосты и собственные хосты у некоторых приложений (например, у SQL Server).

Допиливают сейчас именно интерпретатор CMD. Хотя и хосту кое-что перепало. Копипаст, например.

ВиталийПишите программы, которые делают что-то одно и делают это хорошо.»

Не вижу противоречий. В PowerShell каждый коммандлет делает что-то одно (за редчайшими исключениями). Кто скажет, что «Expand-Archive» умеет записывать DVD или варить кофе — пусть первый кинет в меня камень.

ВиталийПишите программы, которые бы работали вместе.»

Здесь PowerShell уделывает все известные мне оболочки, т.к. оперирует объектами, а не текстом. Т.е. «работать вместе» (передавать данные между коммандлетами) получается гораздо эффективнее. Не надо тратить время на парсинг текста и попытку объяснить следующей команде, что же именно представляет собой этот текст.

ВиталийПишите программы, которые бы поддерживали текстовые потоки, поскольку это универсальный интерфейс.»

Потоки тоже поддерживаются. И если надо передвать именно тест — с этим нет никаких проблем.

То есть PowerShell вполне следует приведённой философии.

ВиталийВот например, зачем запихивать в PS «Создание соединений, символических и жестких ссылок» со своим синтаксисом, если есть mklink? Для чего там «Создание и распаковка архивов», если есть zip и его аналоги?
»

Да потому что указанные коммандлеты — это и есть «аналог zip». На самом деле, ответить на эту претензию очень легко. Надо только осознать, что коммандлеты — это не встроенные возможности оболочки, а именно что внешние команды. И всё сразу встаёт на свои места. Ведь это нормально, что у нас есть команды для выполнения каких-то действий, правда? Это справедливо как для PowerShell, так и для любой другой оболочки.

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

artem: Ведь это нормально, что у нас есть команды для выполнения каких-то действий, правда? Это справедливо как для PowerShell, так и для любой другой оболочки. »

Шелл — как много в этом слове… начало искажаться под воздействием MS.
Все время считал, что команды не зависят от среды запуска, а встроенные в среду команды, нужны только для обслуживания возможностей самой среды, а не сторонних объектов. Неужели ошибался?
С этой точки зрения PS начинает напоминать ACDSee и Nero.

Ну почему же. В bash одни команды, в cmd другие. Даже если они где-то совпадают (например, mkdir) — реализация всё равно разная. Так что команды очень даже зависят от среды. Не вижу причины, почему в какой-то другой оболочке это же действие не может называться New-Item.

Здесь PowerShell уделывает все известные мне оболочки, т.к. оперирует объектами, а не текстом. Т.е. «работать вместе» (передавать данные между командлетами) получается гораздо эффективнее.

Сомневаюсь, что все сторонние утилиты поддерживают эти самые объекты. А вот текст поддерживает любая утилита, работающая в командной строке.

Надо только осознать, что командлеты — это не встроенные возможности оболочки, а именно что внешние команды. И

Почему тогда у этих командлетов свой синтаксис? Ну никак не похоже, что это внешние команды.

Виталий: Сомневаюсь, что все сторонние утилиты поддерживают эти самые объекты. »

Сторонние утилиты — нет, конечно. А вот сторонние коммандлеты — запросто. Я бы сказал, что процентов восемдесят сторонних коммандлетов достаточно годно работают с объектами.

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

Виталий: Почему тогда у этих командлетов свой синтаксис? Ну никак не похоже, что это внешние команды. »

С этим не могу не согласиться. «Не похоже» — правильное слово 🙂

Как я сказал выше, к PowerShell надо привыкнуть. Причём я сейчас скажу гадость в сторону наших евангелистов и MVP, но злоупотребление алиасами (dir вместо Get-ChildItem, md вместо New-Item -ItemType «Directory», знак процента вместо Foreach-Object или вопроса вместо Where-Object и так далее, а также пропуск наименований параметров в случае, когда работает умолчание) только запутывает неподготовленных людей. Из-за этого, в том числе, у меня «привыкание» к PowerShell затянулось на годы. Мне кажется, что если бы все примеры команд, опубликованные в блогах и на форумах, содержали полный синтаксис, то новички испытывали бы гораздо меньше анальной боли.

Отчасти согласен, в контексте % и ?. Но md и dir сразу создают ассоциацию с командами CMD, в то время как Get-Childitem никаких параллелей со знакомыми командами не проводит, а намекает, что теперь надо разучивать новые.

Ассоциации с командами CMD хороши только для тех, у кого большой опыт работы в CMD 🙂 Сейчас таких людей практически не осталось. (Я имею в виду людей, которые уже хорошо разбираются в CMD и ещё плохо в PowerShell).

Кроме того, даже если ассоциации «работают» на тебя, то против работает нарушение целостности. В мозгу не появляется устойчивого понимания, что любая команда подчиняется определённым принципам именования. И вместо этого тебе кажется, что нормальные команды имеют короткие названия, а только некоторые особо сложные команды почему-то называются как-то по-другому.

Я имею в виду именно выработку привычек. Т.е. даже если ты прекрасно понимаешь головой, что это алиас, — но если 99% всех увиденных тобой примеров используют эти алиасы, ты воспринимаешь их именно как команды.

Артем, не нужен большой опыт — dir, ren и md знают все, кто открывал CMD по своему желанию, а не следуя инструкциям на форуме 🙂

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

Более того, я считаю важным указывать простые и знакомые псевдонимы. Я сам далеко не сразу узнал, что могу использовать dir *.jpg вместо Get-Childitem -filter ‘*.jpg’

artem: Надо только осознать, что коммандлеты — это не встроенные возможности оболочки, а именно что внешние команды. »

Сомнительное утверждение, тот-же zip-архив можно создать и без коммандлета, т.е. это и есть базисная возможность PowerShell. Коммандлет дает удобство, так как не надо на этот «чих» искать решение в библиотеке классов MSDN.

Нет, это была возможность .NET, а с появлением командлета стала возможностью PowerShell.

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

Никто не запрещает использовать консольные утилиты, но возникает вопрос — а зачем? Если все можно решить средствами самого PowerShell (речь не идет о форматах, 7z скорее всего не может)?

На самом деле, использую 2 варианта: разворачивание бэкапа, сделанного сразу после настройки системы либо ставлю собственную сборку Windows 7, куда включаю все нужные настройки и программы.
А с Win10 менеджер пакетов пока просто ещё не освоил, хотя его наличие вызывает сильный энтузиазм.
Раньше игрался с разными менеджерами пакетов под Windows, но по тем или иным причинам все были неудобными именно в расчёте «время на освоение»/»время на ручное скачивание». Оказалось проще сделать свою сборку, чем лепить скрипты.

Замечательное начинание, я увидел как установить пачку нужных прог одним скриптом, ninite пользовался, особо не впечатлило, сейчас пользуюсь WPI качанными с торрентов, плюс их в том что там есть много больше и реальная автоустановка, минус что необходимо доверять автору репака.
Я одного не понял, как этим ОБНОВЛЯТЬ установленные программы полностью автоматически, что является ключевой базовой основной фичей любого пакет менеджера? Как сделать чтобы тот же нотепад++ прописался автоматом приложением по умолчанию без залезания в жутко неудобные «новые, они же современные» настройки? Как работает система зависимостей, и есть ли она там вообще?

Жесткие и символические ссылки давно делаю через Total Commander, в гуе это не в пример удобнее.

Тот же тотал коммандер помогает забыть про существование архивов и архиваторов.

Еще есть такая штука как платформа PortableApps, вот она тоже умеет обновлять проги практически автоматом…

Евгений, обновление программы возлагается на саму программу. Обновление пакета пока не предусмотрено, но его можно удалить и установить заново.

Ассоциации файлов реализованы только через системные диалоги, начиная с Windows 8.

Vadim Sterkin: это была возможность .NET, а с появлением командлета стала возможностью PowerShell. »

А если оформить, как скрипт или функцию? Например так (без проверки на существование и без преобразования в полные пути, что необходимо):

При чем тут оформление? Вы используете классы .NET напрямую в своей функции. Командлет избавляет от нбх обращаться к классам. В этом и разница. Примерно такая же, как между программистом и ИТ-специалистом.

Извините, но логики понять не могу. Какая разница будете вы вызывать функцию или командлет? Синтаксис этих действий не будет отличаться ничем, как, например, в этой команде:

Где more, это функция-обвязка над more.com

Логика простая — для решения задачи достаточно знать название командлета и уметь вызывать его справку. При этом и не нужно уметь работать с классами .NET, рыться в MSDN и писать функции. Неужели вы не понимаете, что для этого требуется разный уровень подготовки?

Вы пользуетесь ярлыками для запуска программ или идете для этого каждый раз в Program Files? А если ее там нет, будете по диску рыться? Так вот мне все равно, где лежит программа, если ее открывает ярлык. Равно как мне все равно, какие там классы и функции задействует командлет, если он выполняет задачу.

Хорошо, я вас понял, было бы из-за чего спорить. Только все равно придется рыться в документации, искать описание типов, находить методы и свойства объектов, способы их создания. Например:

Обращаешь внимание на методы и их описание и почему-то хочется залезть в MSDN ))

Троллейбус из буханки хлеба.jpg

Я так понимаю, что никто не спорит с тем, что функциями можно сделать вообще всё, что угодно 🙂 Польза же, очевидно, в том, что теперь конкретно для этого действия отдельную функцию писать не нужно. А значит — во-первых, людям будет проще этим пользоваться (особенно если они не умеют писать функции или не могут позволить себе каждый раз их импортировать), а во-вторых будет больше стандартизации. Это несомненное благо. Согласитесь, тупо, когда в пяти скриптах от пяти разных авторов требуется распаковывать архивы, и каждый решает эту задачу немного по-своему. (Например, одно время был популярен вариант через недокументированный com-объект Windows Explorer).

Я работаю на Windows и Mac, а если настраиваю сервер — то Linux. OS X начисто переустанавливал пару раз, но там всё просто — выбрал дату в TimeMachine 10-15 мин и система готова.
На Windows у меня большинство программ портативные, ставлю только хром ибо иначе не обновляется и пакет программ Adobe, потому с версии СС они качаются через Cretive Cloud. Смысла городить огород с автоматизацией не вижу. PowerShell может и хорош, но мне на Windows нечего автоматизировать, а для Linux и OS X есть bash, которым я уже давно пользуюсь.
Если друг просит «переустанови мне Винду, а то что-то глючит» ставлю систему с внешнего диска своим «фирменным» способом, а остальное пусть сам себе ставит

lesha: OS X начисто переустанавливал пару раз, но там всё просто — выбрал дату в TimeMachine 10-15 мин и система готова. »

Разве это начисто? Так и Windows можно поверх переустановить.

Под «начисто» я имел ввиду установку на новый диск, например после замены HDD на SSD или на новый компьютер. Windows предпочитаю ставить с нуля, потому что с установкой поверх уже наступал на грабли последний раз когда накатил десятку на свой 8.1
Вадим, используете в работе AutoIT? Мне эта система нравится своей простотой и возможностями, было бы интересно узнать ваше мнение об этом средстве

Autoit сейчас в работе не использую, но приходилось 🙂

Предпочитаю портативные сборки и Chocolatey.

В отличие от Get-History, содержащей историю текущей сессии, этот журнал ведется глобально и сохраняется при закрытии окна.

Вау, ну ещё немного и ПШ таки дойдёт до уровня старых версий баша 🙂

С удалением приложений не все так гладко, впрочем.

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

strafer: Вау, ну ещё немного и ПШ таки дойдёт до уровня старых версий баша 🙂 »

Баш, это который не умеет создавать директории без корутилс (mkdir) )) ?

Вот и меня тоже заинтересовал ваш комментарий, по поводу PowerShell скоро догонит баш. Это даже не смешно. Вариант bash_history, кому он вообще нужен, был всегда возможен, но тут уж извините, как настроишь, так и поедешь. А это как-раз и есть юникс-вей (а не одно приложение — одна задача). А bash я бы сравнивал с cmd, это где-то рядом.

Herz Mein: А bash я бы сравнивал с cmd, это где-то рядом.
»

А было бы интересно сравнение cmd, ps, bash.
Не только как среды системного администрирования и исполнения скриптов, а именно как шеллов, программ организующих запуск и взаимодействие сторонних программ, и интерактивного взаимодействия с пользователем.

Чтобы не было непонимания, до этого я вёл и далее веду речь об удобстве интерактивной работы.

Herz Mein: Вот и меня тоже заинтересовал ваш комментарий, по поводу PowerShell скоро догонит баш. Это даже не смешно. »

Т.е. вы твёрдо считаете, что ПШ догнал (а то и перегнал!) современные никсовые шеллы в плане удобства?

Herz Mein: но тут уж извините, как настроишь, так и поедешь. А это как-раз и есть юникс-вей (а не одно приложение — одна задача). »

А где про эту интерпретацию можно почитать? Или вы только что это сами придумали?

Herz Mein: А bash я бы сравнивал с cmd, это где-то рядом. »

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

Просто даже по списку статьи:
— вау-эффекты типа подсветки синтаксиса в никсовых шеллах давно уже обыденность
— про поиск по истории кучей способов вообще странно напоминать
— появление возможности создания временного файла меня вообще в ступор вогнало (хотя к интерактивности это не относится, но вогнало)

Ну и да, мне всё ещё хочется услышать, что такого плохого в том, что mkdir обеспечивается coreutils.

strafer: Просто даже по списку статьи:
— вау-эффекты типа подсветки синтаксиса в никсовых шеллах давно уже обыденность
— про поиск по истории кучей способов вообще странно напоминать
— появление возможности создания временного файла меня вообще в ступор вогнало (хотя к интерактивности это не относится, но вогнало) »

Начинается заламывание рук. Я выбрал те изменения, которые понятнее аудитории этого блога. Полный список по ссылке в конце статьи.

Так я не вам тут отвечаю, а указанными комментариями я проиллюстрировал своё замечание о том, что многим фичам в никсовых шеллах сто лет в обед.

Меня всегда забавляет позиция «они с нас слизали». Взяли лучшее для своих клиентов, тем более те сами это просят — фидбэк-то есть. Вы ведь при любом раскладе будете тыкать в них острой палочкой — если ничего не делать, если изобрести какой-нибудь свой метро еще раз и т.д. Я считаю, что они делают правильно 🙂

Взяли лучшее для своих клиентов

Терминами можно вертеть как угодно, суть понятна всем.

Меня на самом деле эти МСовские подвижки, как и активное продвижение виндовой консоли вами, умиляют на фоне форумских срачиков, в которых никсы перманентно обвиняли в страшных грехах типа «там надо настраивать в консоли», или даже «там можно работать только в консоли». А оказалось-то…

Кроме того, из тех же срачиков можно сделать открытие, что оконный интерфейс придумала МС, а никсы его у неё слизали. Далее, я видел перлы о том, что компиз никсы слямзили с Aero. Учитывая всё это, есть стойкое ощущение, что через несколько лет такие корки начнут мочить и про консоль или, по крайней мере, про отдельные её элементы :)))

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

В этом вы несправедливы, я тычу только когда есть за что. У вас регулярно выходят статьи, к которым нет моих комментариев, что уже опровергает ваши слова 🙂

Меня на самом деле эти МСовские подвижки, как и активное продвижение виндовой консоли вами, умиляют на фоне форумских срачиков, в которых никсы перманентно обвиняли в страшных грехах типа «там надо настраивать в консоли», или даже «там можно работать только в консоли». А оказалось-то…

Основной вектор ваших комментариев тут холиварный, Windows vs. Linux. Вот и сейчас вы подтягиваете в это обсуждение какие-то древние холивары из форумов, которые вы читаете, пытаясь раздуть дискуссию в этом унылом направлении — кто у кого слизал и кто кого в чем упрекал. bash в миллион раз лучше PowerShell? Да и фиг с ним, тут это никому не интересно.

Мое «активное продвижение виндовой консоли» отражает мой личный опыт в немалой степени (и было бы странно, если б я продвигал тут bash). Но я за редким исключением не рассказываю, как настраивать Windows в PowerShell, что видно из списка статей о PowerShell. Даже в этой записи жирным по белому написано слово автоматизация в контексте рутинных задач.

Основной вектор ваших комментариев тут холиварный, Windows vs. Linux

Мое «активное продвижение виндовой консоли»

А я вас за него и не упрекал. На мой взгляд консоль это замечательно. Человечество от всяческой наскальной живописи и прочего подобного пришло к алфавиту и письму. Вместо дебильного тыканья в картинки гораздо лучше общаться с компьютером при помощи текста.

Но я за редким исключением не рассказываю, как настраивать Windows в PowerShell, что видно из списка статей о PowerShell. Даже в этой записи жирным по белому написано слово автоматизация в контексте рутинных задач.

Можно подумать, будто я говорил про настройку из консоли как про что-то плохое. Настройка из консоли — хорошо, автоматизация скриптами — ещё лучше.

Ну вот и пример того, о чём я выше говорил. Человек отдаёт должное ПШ, считая при этом, что никсы в это не могут http://www.outsidethebox.ms/18237/#comment-32751

Честно говоря даже не думал, что придётся настолько мало ждать 🙂

strafer: многим фичам в никсовых шеллах сто лет в обед. »

Так PS и не стОит рассматривать, как шелл, он не для локального администрирования. Решение прикладных задач (вычислить, обработать текст, скачать информацию, отладить и запустить скрипт) — да, решение задач файлового менеджера, лаунчера — скорее нет. Хотя он и не лишен удобств (автодополнение путей, команд и параметров, история, сохранение сессии, псевдонимы, полная настройка строки приглашения (аналог никсовых $PS1 и $PS2, но не переменная, а функция)) Основная задача PS, на мой взгляд, это корпоративное администрирование (за счет продвинутых возможностей PSremoting), а это опять же не требует шелл, как таковой.

Если рассматривать сам хост для запуска PowerShell, cmd или bash, то в виндоус лучший, на мой взгляд, это conemu — настраиваемый, с табами, со сплитом, с фоном, с фулл-скрином и т.д.

Herz Mein: Так PS и не стОит рассматривать, как шелл, он не для локального администрирования. »

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

Herz Mein: автодополнение путей, команд и параметров, история, сохранение сессии, псевдонимы »

То, что в никсовых шеллах существует десятилетиями.

Herz Mein: полная настройка строки приглашения (аналог никсовых $PS1 и $PS2, но не переменная, а функция) »

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

Мастер Йода рекомендует:  Как посмотреть Google IO 2020

Фишечки ПШ в объектах в пайпах, но вот сам интерактив в никсах вылизан гораздо лучше, потому что вылизывание началось давнее и многие пользователи, в т.ч. по совместительству программисты, в консоли реально работают повседневно. Положа руку на сердце, МС как обычно не стесняясь просто подглядела и подтянула годами вымученные под никсами решения.

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

Herz Mein: Так PS и не стОит рассматривать, как шелл, »

Прочтите его название.

strafer: Это видимо завуалированное согласие, что по удобству интерактива он таки в догоняющих. »

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

strafer: То, что в никсовых шеллах существует десятилетиями. »

На счет сохранения сессии я сомневаюсь, автодополнение параметров команд тоже нет, например нельзя ввести `bash —v’, что бы дополнилось до —version

На самом деле это все не принципиально. Для cd, pwd, pushd и т.д. нет никакой разницы, т.е. вообще никакой.

strafer: Опять же объекты эти во многих случаях нужны как велосипеды-костыли »

В PowerShell ВСЁ объект, даже если это один единственный символ. Исходя из этого и вся философия, которая оочень далека от никсовой…

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

Herz Mein: На самом деле я не вижу каких-то явных, незаменимых элементов»

Ну да, из общения с вами создаётся впечатление, что вы в целом не слишком знакомы с возможностями никсовых шеллов.

Herz Mein: которые могли бы для никсового интерпретатора стать киллер-фичей »

Одной мегафичи, конечно, нет. Есть множество вроде бы мелких, которые вместе набирают критическую массу удобства.

Herz Mein: На счет сохранения сессии я сомневаюсь »

Это, как и положено, не является задачей шелла, а реализуется внешними средствами, такими как tmux, screen и т.п. Tmux относительно молодой, но при этом он почти ровесник самого ПШ, а вот screen разрабатывается с 1987 года. 1987 года, Карл.
В общем, не сомневайтесь.

Herz Mein: автодополнение параметров команд тоже нет, например нельзя ввести `bash —v’, что бы дополнилось до —version »

Вы не поверите http://itmages.ru/image/view/4006064/88d9b0b6
И есть ещё много всякого, чего можно автодополнять, а так же способов автодополнения.

Забавно, что вы этим постом продемонстрировали замечательный пример для иллюстрации моего ответа Вадиму http://www.outsidethebox.ms/18237/#comment-32746 🙂

Herz Mein: В PowerShell ВСЁ объект, даже если это один единственный символ. Исходя из этого и вся философия, которая оочень далека от никсовой… »

Так про то и веду речь, что героическое преодолевание с помощью объектов (специально для вас уточнение: не являющихся тривиальным текстом) в ПШ в никсах в огромном числе случаев просто не нужно и чисто текстовыми способами элементарно решается. И вытекает это действительно из архитектуры системы, ПШ её заложник, если хотите.

Ах да, совсем забыл.

Herz Mein: Кроме того, где-то читал, что в ось хотят прикрутить никсовую подсистему, вот тогда будет вообще гибрид, в котором без костылей можно будет юзать нативный юникс-софт (соответствующим образом скомпилированный)… »

Для системного администратора

Введение в Powershell

Задачи автоматизации различных операций, выполняемых системными администраторами, существуют со времен появления первых локальных сетей. Для решения этих задач используются разные программные средства, однако самым распространенным является написание сценариев, например, на языке VBScript или Perl. Но в последнее время все большую популярность получает Windows PowerShell, новая командная оболочка Windows, разработанная в первую очередь для системных администраторов. Она включает интерактивную командную строку и среду исполнения сценариев, которые можно использовать вместе или по отдельности. Ранее PowerShell именовался Monad и поставлялся в виде отдельного приложения, но в Windows Server 2008 (который, по официальным данным, выйдет в феврале следующего года) данный инструмент будет установлен по умолчанию. Также стоит отметить, что Powershell будет работать не только на Server 2008, но и на любой системе, где есть .Net 2.0 (Windows XP, Vista, Server 2003). В отличие от большинства оболочек, которые принимают и возвращают текст, оболочка Windows PowerShell, разработанная на основе среды CRL .NET и платформы .NET Framework, принимает и возвращает объекты .NET, а также использует в своей работе только объекты. Это фундаментальное изменение делает возможным применять совершенно новые средства и методы администрирования и конфигурирования систем Windows.

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

Поговорим о том, какие средства предлагает данный инструмент системным администраторам и какие задачи можно решать с его помощью. Большинство оболочек, в том числе знакомая каждому админу Cmd.exe и оболочки SH, KSH, CSH и BASH систем UNIX, выполняют команду или служебную программу в новом процессе и представляют результаты пользователю в виде текста. За время существования этих оболочек были разработаны многие программы обработки текста, поддерживающие этот механизм взаимодействия, такие как sed, AWK и PERL. Некоторые команды встроены в эти оболочки и выполняются в процессе самой оболочки. Примерами могут служить команды typeset и dir в оболочках KSH и Cmd.exe соответственно. В большинстве оболочек встроенных команд немного, поэтому для них создано большое число служебных программ.

Однако Windows PowerShell сильно отличается от других оболочек:

  • Windows PowerShell обрабатывает не текст, а объекты платформы .NET. Также PowerShell позволяет напрямую вызывать объекты .Net и таким образом управлять любыми Com ActiveX сущностями.
  • Windows PowerShell включает множество встроенных команд, имеющих унифицированный интерфейс. Таких, например, как команды для работы с WMI (Get-WmiObject).
  • Все команды оболочки обрабатываются одним синтаксическим анализатором, в то время как во многих других оболочках каждому средству соответствует отдельный анализатор. Это значительно облегчает изучение команд.
  • Powershell позволяет запускать унаследованные VBS-сценарии, так что вы без труда сможете использовать уже имеющиеся наработки.

И что самое важное: в оболочке Windows PowerShell можно использовать традиционные средства Windows, такие как Net, SC и Reg.exe. Думаю, всем администраторам приходилось неоднократно сталкиваться с данными средствами, и возможность использовать их в своих сценариях будет также не лишней.

Основные понятия

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

Командлеты можно идентифицировать по их именам, которые составлены из глагола и существительного, разделенных дефисом (-), например Get-Help, Get-Process и Start-Service. Большинство командлетов Windows PowerShell очень просты, и предполагается, что они будут использоваться вместе с другими командлетами. Например, командлеты категории «get» только возвращают данные, командлеты «set» только задают или изменяют значения элементов данных, командлеты «format» только форматируют данные, а командлеты «out» только направляют вывод в указанное место назначения.

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

Установка

Обсудив основные понятия PowerShell, приступим к установке. Требования к системе достаточно стандартны: Windows XP с пакетом обновлений 2, Windows 2003 с пакетом обновлений 1 или более поздние версии Windows. Также требуется Microsoft .NET Framework 2.0, который можно скачать по адресу [1]. Процесс установки на локальную машину стандартен, необходимо лишь запустить установочный файл. Также авторы PowerShell предусмотрели возможность автоматической установки оболочки. Для этого необходимо запустить файл дистрибутива с параметром /quiet. Например:

Так что вы можете без труда развернуть оболочку сразу на большом количестве машин. После установки PowerShell вам достаточно набрать в командной строке Windows PowerShell, и вы окажетесь в командной строке данной оболочки. Наберите «help», как видите, PowerShell содержит множество различных команд (см. рис. 1).

Рисунок 1. Команды PowerShell

Отдельно хотелось бы отметить те команды, которые пришли из мира UNIX. На самом деле эти команды являются только алиасами к реальным командам Power Shell. Сделано это специально для удобства работы администраторов, привыкших к UNIX-среде. Для того чтобы получить список таких алиасов, наберите команду alias (см. рис. 2).

Рисунок 2. Команды PowerShell, пришедшие из UNIX

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

Но пока напишем несколько простых сценариев с помощью имеющегося набора команд:

Листинг 1. Получение времени на локальной машине
$strComputer = «.»
$colItems = get-wmiobject -class «Win32_UTCTime» -namespace «root\CIMV2» -computername $strComputer
foreach ($objItem in $colItems) <
write-host «Day: » $objItem.Day
write-host «Day Of Week: » $objItem.DayOfWeek
write-host «Hour: » $objItem.Hour
write-host «Milliseconds: » $objItem.Milliseconds
write-host «Minute: » $objItem.Minute
write-host «Month: » $objItem.Month
write-host «Quarter: » $objItem.Quarter
write-host «Second: » $objItem.Second
write-host «Week In Month: » $objItem.WeekInMonth
write-host «Year: » $objItem.Year
write-host
>

Как видите, синтаксис похож на VBScript, так что особых проблем с изучением возникнуть не должно. Сохраняем в текстовом файле с расширением PS1.

Настройка

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

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

В случае установки по умолчанию вы должны получить статус Restricted. Для того чтобы сменить этот статус, воспользуйтесь командой:

Рассмотрим, какие статусы политики выполнения возможны:

  • Restricted – эта политика выполнения по умолчанию. Допускает отдельные команды, но сценарии выполнять нельзя.
  • AllSigned – здесь выполнение сценариев разрешено, но необходимо наличие цифровой подписи надежного издателя на всех сценариях и файлах конфигураций, включая сценарии, написанные на локальном компьютере. Также при такой политике запрашивают подтверждение перед выполнением сценариев надежных издателей. Однако при этом существует опасность того, что подписанные, но вредоносные сценарии выполняются.
  • RemoteSigned – при таком статусе политики выполнение сценариев также разрешено. Необходимо наличие цифровой подписи надежного издателя на всех сценариях и файлах конфигураций, загруженных из Интернета (включая электронную почту и программы мгновенного обмена сообщениями). Нет необходимости в цифровых подписях на сценариях, запускаемых с локального компьютера. Не запрашивают подтверждения перед выполнением сценариев надежных издателей. Подписанные, но вредоносные сценарии также выполняются.
  • Unrestricted – самая демократичная политика, позволяет запускать неподписанные сценарии. Сценарии и файлы конфигурации, загруженные из Интернета (включая Microsoft Outlook, Outlook Express и Windows Messenger), выполняются после предупреждения, что данный файл был загружен из Интернета. Как и следовало ожидать, при таком статусе также возможно выполнение вредоносных сценариев. Думаю, использование данного статуса политики выполнения возможно только на тестовых машинах, так как в реальных сетях это крайне небезопасно.

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

Итак, устанавливаем статус политики RemoteSigned:

Запускаем PS1-файл. Для этого достаточно просто набрать в командной строке PowerShell имя файла. Результатом выполнения сценария будет информация о времени на локальной машине.

Итак, на примере такого незамысловатого сценария мы настроили систему политики выполнения сценариев PowerShell и убедились в работоспособности интерпретатора. Пришло время рассмотреть более сложные, прикладные сценарии.

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

Листинг 2. Получение информации о события�
$strComputer = «.» //Выполняем на локальной машине
$colItems = get-wmiobject -class «Win32_NTLogEvent» -namespace «root\CIMV2» -computername $strComputer
# Обходим все записи в журнале
foreach ($objItem in $colItems) <
# Категория
write-host «Category: » $objItem.Category
# Значение категории
write-host «Category String: » $objItem.CategoryString
# Имя компьютера
write-host «Compute rName: » $objItem.ComputerName
write-host «Data: » $objItem.Data # данные
# Код события
write-host «Event Code: » $objItem.EventCode
# Идентификатор события
write-host «Event Identifier: » $objItem.EventIdentifier
# Тип события
write-host «Event Type: » $objItem.EventType
# Добавленные комментарии (если есть)
write-host «Insertion Strings: » $objItem.InsertionStrings
# Файл журнала
write-host «Logfile: » $objItem.Logfile
# Текст сообщения
write-host «Message: » $objItem.Message
# Номер записи
write-host «Record Number: » $objItem.RecordNumber
# Имя источника
write-host «Source Name: » $objItem.SourceName
# Время создания сообщения
write-host «Time Generated: » $objItem.TimeGenerated
# Время записи
write-host «Time Written: » $objItem.TimeWritten
write-host «Type: » $objItem.Type # Тип
write-host «User: » $objItem.User # Имя пользователя
write-host
>

Как видите, сценарий прост в написании. В репозитории Microsoft [4] вы найдете большое количество сценариев PowerShell, предназначенных для работы с объектами Active Directory, файлами, операционной системой, сетью и т. д. Однако все эти сценарии ориентированы на получение свойств различных объектов и не осуществляют создание каких-либо объектов средствами PowerShell.

Работаем с групповыми политиками

Итак, давайте создадим новый объект групповых политик (GPO), используя Windows PowerShell. Такой сценарий будет иметь следующий вид:

Листинг 3. Создание нового объекта групповой политики
Dim GPM # Объявляем массив GPM
# Объект класса GPMgmt.GPM
Set GPM = CreateObject(«GPMgmt.GPM»)
# Переменная данного класса
$gpm = New-Object -ComObject GPMgmt.GPM
# Получаем константы данного класса
$gpmConstants = $gpm.GetConstants()
$gpmDomain =$gpm.GetDomain(«Mydomain.local», «», $gpmConstants.UseAnyDC)
# Подключаемся к домену, замените Mydomain.local на нужный
# Создаем новую политику
$gpmNewGpo = $gpmDomain.CreateGPO()
# С именем PowerShell GPO
$gpmNewGpo.DisplayName = «PowerShell GPO»

Рассмотрим более подробно данный сценарий, так как в нем отражены преимущества PowerShell. В начале сценария мы создаем экземпляр класса GPMgmt.GPM, который дает доступ к большинству функций GPMC:

$gpm = New-Object -ComObject GPMgmt.GPM

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

$gpmDomain =$gpm.GetDomain(«Mydomain.local», «», $gpmConstants.UseAnyDC)
И затем, собственно, создается новый объект групповой политики:
$gpmNewGpo = $gpmDomain.CreateGPO()
$gpmNewGpo.DisplayName = «PowerShell GPO»

Теперь, когда вы знаете, как создать объект GPO, давайте откроем существующий объект. Для этого нам придется немного модифицировать уже имеющуюся программу. У вас все еще есть ссылка на домен, $gpmDomain, поэтому добавьте следующее:

Листинг 4. Получение информации о групповой политике
$gpmExistingGpo = $gpmDomain.GetGPO(«<31B2F340-016D-11D2-945F-00C04FB984F9>«)
# Открываем уже существующую групповую политику, используя ее GUID
$gpmExistingGpo.DisplayName
# Получаем имя данной политики. Сохраняем отчет в файл
$gpmExistingGpo.GenerateReportToFile($gpmConstants.ReportHTML,».\DefaultDomainPolicyReport.html»)

Вы получите полный отчет в формате HTML о параметрах политики домена по умолчанию, но вы можете использовать любой из методов и свойств, например, ModificationTime, который сообщит вам, когда объект GPO в последний раз изменялся, чтобы узнать, когда изменялись какие-либо из параметров объекта GPO.

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

Листинг 5. Получение информации об изменениях GPO за последние сутки
$gpmSearchCriteria = $gpm.CreateSearchCriteria()
# Мы хотим получить информацию обо всех групповых политика�
# в домене, поэтому критерий поиска нам вводить не нужно
$gpmAllGpos = $gpmDomain.SearchGPOs($gpmSearchCriteria)
# Ищем все групповые политики в домене
foreach ($gpmGpo in $gpmAllGpos)
<
if ($gpmGpo.ModificationTime -ge (get-date).AddDays(-1)) <$gpmGpo.DisplayName>
# Проверяем, какие групповые политики изменялись за последние 24 часа
>

Обратите внимание на знак операции -ge, означающий «больше или равно». Он может показаться вам странным, если вы привыкли к знакам операций «и» в других языках написания сценариев или программирования. Однако эти знаки операций используются для перенаправления, например, для перенаправления выходных данных в файл, и поэтому не могут использоваться в качестве знаков операций сравнения в Windows PowerShell.

Интересные нововведения

Кроме описанных выше синтаксических конструкций, позволяющих автоматизировать различные задачи системного администрирования, PowerShell обладает также и рядом принципиально новых решений, таких как демонстрации возможных последствий работы сценария. То есть с помощью конструкции -whatif демонстрируется то, что будет сделано, и предсказывается эффект, но никаких изменений в системе и действий над объектами не производится. Приведу пример работы небольшого сценария, в котором рекурсивно обходится папка c:\Program Files, ищет файлы *.ini и пытается их удалить:

> get-childitem “c:\Program Files” -include *.ini -recurse | remove-item –whatif

What if: Performing operation “Remove File” on Target

“C:\Program Files\ABBYY Lingvo 12\LingvoCE\Setup.ini”.

What if: Performing operation “Remove File” on Target

“C:\Program Files\ABBYY Lingvo 12\LingvoPalm\SetupPalm.ini”.

What if: Performing operation “Remove File” on Target

“C:\Program Files\ABBYY Lingvo 12\BITSetup.ini”.

What if: Performing operation “Remove File” on Target

“C:\Program Files\Adobe\Acrobat 7.0\Setup Files\RdrBig709\ENU\0×009.ini”.

What if: Performing operation “Remove File” on Target

“C:\Program Files\Adobe\Acrobat 7.0\Setup Files\RdrBig709\ENU\Abcy.ini”.

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

> get-childitem “c:\Program Files” -include *.ini -recurse | remove-item –confirm

Confirm

Are you sure you want to perform this action?

Performing operation “Remove File” on Target

“C:\Program Files\ABBYY Lingvo 12\LingvoCE\Setup.ini”.

[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help (default is “Y”):

Здесь вместо -whatif используется команда -confirm. В результате перед выполнением действия на консоль выводится запрос на подтверждение выполнения указанного действия. Стоит отметить, что параметры -whatif и -confirm можно применять практически к любым командам Powershell.

Также хотелось бы сказать несколько слов об объектности интерпретатора PowerShell. Вот, например, поиск процесса по маске notep*:

> get-process notep*

Handles NPM(K) PM(K) WS(K) VM(M) CPU(s) Id ProcessName

47 3 1724 3772 33 0,41 236 notepad

47 3 1704 3732 33 0,30 2900 notepad

Все внутри PowerShell – это объекты на примере поиска в памяти процесса notepad и присвоения объекта переменной $prc:

> $prc= get-process notep*

Получаем содержимое объекта $prc:

> $prc*

Handles NPM(K) PM(K) WS(K) VM(M) CPU(s) Id ProcessName

47 3 1724 3772 33 0,41 236 notepad

47 3 1704 3732 33 0,30 2900 notepad

К любому атрибуту объекта PowerShell можно обратиться. Возьмем, например, атрибут Id:

> $prc.Id

236

2900

Также стоит обратить внимание на то, что Powershell поддерживает режим автодополнения команд и параметров, как в bash. К примеру, напечатав в командной строке $prc и нажав клавишу , получим $prc.Id. При этом автозаполнение действует не только для объектов, но и для параметров команд и путей файловой системы.

Далее рассмотрим свойства объекта и его методы. Знак «|», знакомый администраторам, работавшим с Shell и Perl, в PowerShell передает не просто текст, а настоящие объекты по конвейеру. Причем здесь можно создавать конвейеры любой длины. Например:

> $prc| format-list -property *

__NounName : Process

Name : notepad

Handles : 47

VM : 34541568

WS : 3862528

PM : 1765376

NPM : 2920

> $prc| get-member

TypeName: System.Diagnostics.Process

Name MemberType Definition

Handles AliasProperty Handles = Handlecount

Name AliasProperty Name = ProcessName

NPM AliasProperty NPM = NonpagedSystemMemorySize

PM AliasProperty PM = PagedMemorySize

VM AliasProperty VM = VirtualMemorySize

WS AliasProperty WS = WorkingSet

Существует также несколько способов уничтожения процесса. Для примера остановим процесс notepad:

> $prc| stop-process

> get-process notep* | stop-process

> get-process notep* | kill

В результате выполнения любой из этих команд процесс notepad будет закрыт.

Приведу еще несколько примеров работы с конвейерами в PowerShell.

Произведем сортировку объектов по свойству WS (working set) и выбор 5 процессов, занимающих больше всего памяти:

> get-process | sort-object -property WS –descending | select-object -first 5

Handles NPM(K) PM(K) WS(K) VM(M) CPU(s) Id ProcessName

605 27 52820 38652 226 476,11 2268 ICQLite

637 24 37692 32380 165 79,25 1716 IEXPLORE

445 17 28676 25672 490 187,44 2588 WINWORD

975 38 44960 20776 350 14,13 3120 OUTLOOK

283 5 26748 20392 136 2,78 1580 powershell

Другая задача – проверить, сколько свободного места есть на дисках, на которые возможна запись:

> gwmi win32_logicaldisk

DeviceID : A:

DriveType : 2

ProviderName :

FreeSpace :

Size :

VolumeName :

DeviceID : C:

DriveType : 3

ProviderName :

FreeSpace : 15472779264

Size : 52427898880

VolumeName :

DeviceID : D:

DriveType : 3

ProviderName :

FreeSpace : 58742120448

Size : 107611336704

VolumeName : Новый том

DeviceID : E:

DriveType : 5

ProviderName :

FreeSpace :

Size :

VolumeName :

Нам нужны диски, на которые можно писать. У них type=3:

> gwmi win32_logicaldisk -filter “drivetype = 3″

DeviceID : C:

DriveType : 3

ProviderName :

FreeSpace : 15472779264

Size : 52427898880

VolumeName :

DeviceID : D:

DriveType : 3

ProviderName :

FreeSpace : 58742120448

Size : 107611336704

VolumeName : Новый том

Затем нужно получить параметры deviceid, freespace:

> gwmi win32_logicaldisk -filter “drivetype = 3″ | select deviceid,freespace

deviceid freespace

C: 15472590848

D: 58742120448

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

> gwmi win32_logicaldisk -filter “drivetype = 3″ | % < $_.deviceid; $_.freespace/1GB >

C: 14,4099731445313

D: 54,7078628540039

Для примера выберем все файлы, размер которых больше, чем 200 Кб, и отсортируем их в нисходящем порядке:

> Get-ChildItem C:\Windows | Where-Object <$_.Length -gt 200KB>| Sort-Object Length –Descending

Mode LastWriteTime Length Name

-a— 05.05.2005 4:28 14396416 RTHDCPL.EXE

-a— 04.05.2005 5:16 9697280 RTLCPL.EXE

-a— 04.05.2005 21:01 2805248 ALCWZRD.EXE

-a— 26.10.2007 16:59 2012987 WindowsUpdate.log

-ar– 04.08.2004 16:00 1086058 SET4.tmp

-a— 29.05.2007 15:01 1051257 iis6.log

-ar– 04.08.2004 16:00 1042903 SET3.tmp

-a— 04.08.2004 16:00 1032192 explorer.exe

-a— 16.11.2006 17:22 1030102 setupapi.log.0.old

-a— 17.04.2006 10:54 786065 setuplog.txt

-a— 10.07.2007 11:17 737280 iun6002.exe

-a— 29.05.2007 15:01 708085 FaxSetup.log

—– 17.04.2005 9:20 487424 RtlExUpd.dll

-a— 29.05.2007 15:01 364112 ocgen.log

-a— 22.10.2007 10:58 363933 setupapi.log

-a— 29.05.2007 15:01 336583 tsoc.log

-a— 22.10.2007 15:08 316640 WMSysPr9.prx

-a— 29.10.1998 15:45 306688 IsUninst.exe

-a— 04.08.2004 16:00 283648 winhlp32.exe

-a— 04.08.2004 16:00 256192 winhelp.exe

-a— 29.05.2007 15:01 248705 comsetup.log

-a— 29.05.2007 14:53 239096 msmqinst.log

-a— 18.06.2007 10:38 236773 svcpack.log

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

get-service | ConvertTo-Html -Property Name,Status | foreach <

if ($_ -like “*

Running

*”)

<$_ -replace “ ”, “

”>

else <$_ -replace “ ”, “

”>> > .\get-service.html

Результатом выполнения данного сценария будет HTML-файл, аналогичный изображенному на рис. 3.

Немного о поиске справочной информации

Powershell обладает широкими возможностями по поиску справочной информации, получать которую можно находясь непосредственно в интерпретаторе, с помощью get-help. Вот несколько примеров:

// Получаем справочную информацию по команде get-process

> get-help get-process

// Получаем более детальную информацию по той же команде

> get-help get-process -detailed

// Получаем справочную информацию по командам, работающим с XML

> get-help *xml*

// Аналогичный пример, только для команд, работающих с WMI

> get-help *wmi*

Вместо get-help желающие могут использовать команду man. Таким образом любой специалист, который пришел из мира UNIX, сможет сделать так:

> man get-process

> man get-process -detailed

> man *xml*

Несмотря на то что примеры, которые приведены, работали только с текстовыми данными, это не означает, что Powershell не умеет работать с графикой. Если нам требуется создать и отобразить из скрипта какой-либо графический интерфейс, можно воспользоваться WPF (Windows Presentation Framework), встроенным в .NET.

Следующий скрипт на Powershell создает экранную форму с кнопкой «Push me» (см. рис. 4):

[void][reflection.assembly]::LoadWithPartialName(

“System.Windows.Forms”)

$form = new-object Windows.Forms.Form

$form.Text = “My First Form”

$button = new-object Windows.Forms.Button

$button.text=”Push Me!”

$button.Dock=”fill”

$button.add_click(<$form.close()>)

$form.controls.add($button)

$form.ShowDialog()

Этот пост February 20, 2008 at 7:27 pm опубликовал molse в категории Shell и скрипты. Желающие могут оформить RSS подписку на комменты. Both comments and trackbacks are currently closed.

Изучение PowerShell

Я пользуюсь по работе скриптами PowerShell — но мое использование их сводится к простой редактуре в случае необходимости и в поверхностном понимании того как именно они работают. Хотелось бы улучшить это положение, научиться свободно кодить на PS и использовать возможности этого языка на полную катушку в своем рабочем окружении.

В наличии следующие книги

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

Критерий завершения

Самостоятельное написание скриптов.

Личные ресурсы

Время, два учебника и 1 видеокурс по PS

Экологичность цели

Это объективно необходимый мне навык для дальнейшего профессионального роста.

Изучение PowerShell

Изучение скриптового языка программирования от простого к сложному.

PowerShell — всё по этой теме для программистов

Всем привет, Мы рады сообщить, что бета-версия Windows server 2008 R2 поддерживает использование PowerShell в службах Remote Desktop. Теперь вы можете настраивать и управлять всеми службами и компонентами ролей RDS с помощью PowerShell. Например, ниже приведены несколько задач управления, которые теперь можно выполнять с помощью PowerShell Просмотр и редактирование настроек конфигурации сервера удаленного рабочего стола…

Использование PowerShell для защиты от Conficker (включение и отключение AutoRun.inf)

На главной странице MSN.com сегодня приведены сведения о новом черве, Conficker, который распространяется через старые добрые трюки с autorun.inf. Он инфицирует устройства USB так, что при подключении этих устройств в другой компьютер вредоносный код автоматически запускается и поражает машину. Статья ссылается на публикацию в блоге Ника Брауна (Nick Brown), который описывает различные способы отключения файлов…

Коммандлеты групповых политик в Windows 7

Лилия Гутник (Lilia Gutnik) опубликовала ЗДЕСЬ запись с примером коммандлетов групповых политик Windows 7. Посмотрите. Экспериментируйте, не скучайте, подключайтесь! Джеффри Сновер (Jeffrey Snover) [MSFT] Windows Management Partner Architect Посетите английский блог команды Windows PowerShell: http://blogs.msdn.com/PowerShellПосетите Windows PowerShell ScriptCenter: http://www.microsoft.com/technet/scriptcenter/hubs/msh.mspx Перевод: Виктор Горбунков

Отладка сценария PowerShell с помощью редактора ISE

Привет, писатели и потребители сценариев с ошибками.В этом сообщении описываются основы работы с графическим отладчиком в ISE. Здесь приведено множество отличных рекомендаций, а также несколько советов и трюков.Отладчик поддерживает как коммандлеты, так и пользовательский интерфейс. Коммандлеты включают Enable/Disable/Get/Set/Remove-PsBreakpoint и Get-PsCallStack.Основной способ работы – расставить в сценарии точки останова, продолжать работу (F5) для перехода от одной…

Заметки на полях

О чем и для чего этот сайт я пока не решил. Будем считать это тестированием WordPress

PowerShell для программиста. Передача параметров в функцию.

Лично для меня PowerShell (PoSh)– это не шел, а скорее средство быстрой разработки под .NET. Он очень могуч (и вообще прекрасен), но имеет и ряд особенностей.

В интернете есть кучи описаний по языку, но почему-то на особо засадные вещи внимание не обращается. Поэтому напишу только о них. А как 2+2 сделать, думаю без проблем найдется где угодно.

Итак, синтаксис PowerShell традиционен, т.е. си-подобный (или php-подобный, или perl-подобный). И эта схожесть дает ложную уверенность, что все можно делать привычными конструкциями. И ведь можно, в смысле ругаться PoSh не станет, но и работать оно тоже не будет. Или хуже – иногда будет, а иногда нет.

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

  • вызов функций всегда делать в стиле командной строки – ключами, а не традиционно в скобках, в PoSh скобки для другого
  • пайпы (потоки ввода/вывода) есть везде, даже если кажется что их нет
  • условия пишутся не угловыми скобками, а ключами : -lt, -gt, -eq, … (JS style)
  • при возврате коллекции из функции, может произойти преобразование к другому типу, если не позаботиться об обратном

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

Дальше подробно распишу про типовые ошибки с передачей параметров (точнее особенностями синтаксиса PowerShell) и заодно будет понятно:

  • как передавать типизированные и не типизированные значения
  • как устанавливать значение параметра по-умолчанию
  • как передавать значение по ссылке [ref]
  • как передавать в параметре другую функцию или произвольный код (например для callback)

Сначала просто про базовый синтаксис на примере:

Оба варианта вызова в данном случае будут работать как ожидается (получим дабл Васю).

А теперь чуть сложнее – на вход два параметра и немного логики внутри
(-gt значит greater than, т.е. “>”):

При выполнении мы увидим разные результаты выполнения:

Предполагается, что первый параметр “Вася” и его длина 4 символа. Почему при вызове со скобками он вдруг “короче 4”?
Первый раз меня это выбило дня на два 🙂

Любители типизации входных параметров, результат получат вроде логичнее, но это только замаскирует ошибку:

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

Вызовем заново, посмотрим:

Т.е. оказывается вызов: hello(“Вася”, “Костя”) в первый параметр отправляет массив каких-то объектов, а мы-то ждем, что туда попадет строка «Вася».

Конечно, можно посмотреть, что это за массив, определить его длину и т.п., но обойдемся, сразу скажу – это коллекция из двух строк «Вася» и «Костя». И отсюда дважды обескураживающее: “Вася Костя короче 4” (при выводе на экран массив отобразился одной строкой визуально явно длиннее 4, а сравнивается вообще число элементов массива т.е. 2).

Короче говоря вызов:

Т.е. любое перечисление в скобках – это всегда массив (точнее список).

Наш пример будет корректно работать так:

Но надежнее так:

На мой взгляд, это первое что нужно хорошо запомнить про PoSh, если когда-либо писал или пишешь на других языках. Дальше про варианты передачи параметров.

Передача значения по-умолчанию

Тут все совсем просто, т.к. синтаксис не отличается от других языков

Передача параметра по ссылке ([ref])

Передача параметра по ссылке делается приведением к типу [ref] (это специальный класс PowerShell). Две особенности:

  • обращаться к переданному по ссылке объекту/параметру нужно через свойство .Value
  • при вызове функции заключать параметр вместе с [ref] в скобки, иначе будут передаваться отдельно класс [ref] и отдельно значение параметра, списком из 2-х элементов (те грабли, о которых писал выше).

На экране будет “Bye!”

И еще одна интересная штука – передача функции или блока кода как параметр

Тоже в общем ничего сложного, рассмотрим функцию с колбэком:

Т.е. просто передаем блок кода, который выполнится в контексте того места, где ему сделают Invoke.

Буду рад, если описанное сэкономит Вам хоть немного времени. 🙂

Добавить комментарий