Здравствуйте, DemAS, Вы писали:
DAS>Добрый день.
DAS> Объясните пожалуйста, что это такое. Новая командная строка? А в чем ее преимущество перед cmd.exe ?
DAS> Заранее спасибо.
Microsoft уже демонстрировала возможности PowerShell на выставке Linuxworld, в частности функции преобразования стандартных команд Unix в их аналоги для Windows.
Здравствуйте, DemAS, Вы писали:
DAS>Добрый день.
DAS> Объясните пожалуйста, что это такое. Новая командная строка? А в чем ее преимущество перед cmd.exe ?
Вот здесь можно посмотреть на примеры и сравнение с ksh Это — непосредственно страничка MSH
Здравствуйте, DemAS, Вы писали:
DAS>Добрый день.
DAS> Объясните пожалуйста, что это такое. Новая командная строка? А в чем ее преимущество перед cmd.exe ?
DAS> Заранее спасибо. Основные идеи PowerShell:
командная строка как основной интерфейс администрирования;
концепция ObjectFlow (элементом обмена информацией является объект);
переработка существующих команд, утилит и оболочки командной строки;
интеграция командной строки, COM- и .NET-объектов;
работа с произвольными источниками данных в командной строке по принципу файловой системы.
Поэтому всё представлено в виде объектов. Всё с чем мы имеем дело – это объекты.
Имена команд отражают выполняемую ими задачу. Мы все знаем десяток, а то и больше различных команд (md, cd, format c, однако порой приходится сверяться со справочной системой, да и порой названия не совсем очевидные. Ну а если эту команду используешь пару раз в жизни, то запомнить её нет никакой возможности.
PowerShell заменяет старую концепцию именования команд по типу выполняемых ими действий на новую, в которой команды имеют вид «действие-объект» (если на английском, то «Verb-Noun»). Глагол описывает действие (напр. get или set), а существительное — его цель (process или location). Стандартный набор глаголов перекрывает большинство задач (get, set, add, remove). Например, следующая команда возвращает информацию о системном времени:
PS C:\> get-date
9 октября 2006 г. 16:53:30
Pipeline
Этот механизм передачи данных между различными модулями уже давно стал частью многих программных систем. Pipeline в PowerShell пригоден не только для передачи данных в виде текстовых файлов, как было раньше, а и в виде структурированных .NET-объектов. Так называемые Strong Type Objects – это объекты, в которых сохраняются не только сами данные, но и структура, в которую они организованы.
Подобный подход обладает рядом преимуществ. Например, при сохранении структуры данных отпадает необходимость писать отдельные скрипты, осуществляющие как упаковку данных на стороне отправителя, так и распаковку данных на стороне получателя.
PowerShell поддерживает возможность перенаправления данных, возвращенных процессом, следующему приложению или в указанный пользователем файл. Для задания следующего обрабатывающего приложения используется символ "|". Встретив такой символ, командная строка передаст выходные данные одной команды в другую, но уже в качестве входных параметров. Таким образом можно выстроить цепь команд.
Cmdlet – один из столпов Monad
CMDLets (произносится как "command-lets") – это утилиты, предназначенные для выполнения часто используемых заданий. Они являются одной из основ функциональности MSH. CMDLet представляет собой мини-программы внутри MSH, каждая из которых отвечает за определенную функцию командной строки. Они являются управляемыми объектами, которые создаются с помощью одного из языков Microsoft .NET. Удобство состоит в том, что мы можем разрабатывать собственные или скачивать написанные сторонними производителями CMDLets для расширения необходимой нам функциональности.
Provider model – навигация по иерархическим структурам данных
Основная идея состоит в том, что MSH может работать с иерархически представленными данными, как с файловой системой. Теперь в виде иерархического дерева будут также представлены реестр, Active Directory, хранилища сертификатов цифровых подписей и некоторые другие системы хранения данных ОС. Это должно существенно облегчить многие из ежедневных задач.
В PowerShell есть набор стандартных провайдеров:
Alias – Псевдонимы Windows PowerShell;
Certificate – Сертификаты X509 для цифровых подписей;
Environment – Переменные среды Windows;
FileSystem – Диски файловой системы, каталоги и файлы;
Function – Функции Windows PowerShell;
Registry – Реестр Windows;
Variable – Переменные Windows PowerShell.
Алиасы или псевдонимы (Aliases)
Как понятно из названия, псевдоним представляет собой альтернативное имя CMDLet’ а или элемента команды – например, функции, сценария, файла или исполняемого файла.
Поскольку поначалу названия команд немного сбивают с толку, то разработчики для облегчения миграции включили ряд псевдонимов, которые позволяют пользователям Unix и Cmd использовать в Windows PowerShell знакомые им имена команд. Посмотреть доступные псевдонимы можно командой get-alias
Windows(R) PowerShell
Copyright (C) 2006 Microsoft Corporation. All rights reserved.
PS C:\> get-alias
CommandType Name Definition
----------- ---- ----------
Alias ac Add-Content
Alias asnp Add-PSSnapin
Alias clc Clear-Content
Alias cli Clear-Item
…
Если кому интересно, то о тёмной Редмондской лошадке можно почитать вот тут: http://life.screenshots.ru/category/the-code-inside/windows-powershell/ — на русском языке.
Основные англоязычные ресурсы уже упоминали. Ну и как обычно, спрашивайте в поисковых системах.
OLE>Microsoft уже демонстрировала возможности PowerShell на выставке Linuxworld, в частности функции преобразования стандартных команд Unix в их аналоги для Windows.
OLE>Это убийца линуха
это РСДН аналог ЛОРовского "все, теперь винда умрет"???
Здравствуйте, HiSH, Вы писали:
HSH>Вот здесь можно посмотреть на примеры и сравнение с ksh
Не знаток ksh, но показалось, что авторы специально изгалялись "как сделать позаковыристее на ksh, чтобы unix suxx"
Или под никсами всё действительно так удручающе, что на каждый чих нужно делать grep?
Здравствуйте, Кодт, Вы писали:
К>Здравствуйте, HiSH, Вы писали:
HSH>>Вот здесь можно посмотреть на примеры и сравнение с ksh
К>Не знаток ksh, но показалось, что авторы специально изгалялись "как сделать позаковыристее на ksh, чтобы unix suxx" К>Или под никсами всё действительно так удручающе, что на каждый чих нужно делать grep?
Ну там же по пайам текст гоняется — куда тут без регэкспов?
Здравствуйте, Кодт, Вы писали:
К>Здравствуйте, HiSH, Вы писали:
HSH>>Вот здесь можно посмотреть на примеры и сравнение с ksh
К>Не знаток ksh, но показалось, что авторы специально изгалялись "как сделать позаковыристее на ksh, чтобы unix suxx"
Ага.
К>Или под никсами всё действительно так удручающе, что на каждый чих нужно делать grep?
Если не знать ключей ps (и лениться почитать про них), то да.
Здравствуйте, Кодт, Вы писали:
_>>Ну там же по пайам текст гоняется — куда тут без регэкспов?
К>Есть разница между dir *.txt и dir|grep ".txt"
Просто с объектами как-то красивей выходит, чем с plain text. Вот написал:
which someScriptINeedNoLonger | del
и даже заработало!
В стиле Unix это было бы самое меньшее xargs. Один скрипт берет аргументы из stdin, другой из командной строки... а здесь всё как-то более единообразно.
P. S. Вот мой which. Для обыкновенного cmd.exe Интересно, в PowerShell есть свой which?
@echo off
if "%~1"=="" (
echo Usage:
echo which ^<filename^> [folderlist]
echo.
echo Finds file with specified name in PATH or in the folder list you specify.
echo Automatically appends extensions from PATHEXT ^(%PATHEXT%^).
echo.
echo Examples:
echo which cmd
echo which boost %%include%%
exit /b 1
)
set target=%~1
if "%~2" neq "" (
set where=%~2
) else (
set where=%path%
)
:: As is? ::
call :test "%target%"
:: It doesn't want to work with ';' :( ::
call :loop "%pathext:;=:%"
goto :EOF
:loop
for /f "usebackq tokens=1* delims=:" %%i in ('%~1') do (
rem i -- current extension from PATHEXT
rem j -- all the rest
call :test "%target%%%i"
if "%%j" neq "" call :loop "%%j"
rem This 'loop' will run for only one iteration.
)
:test
set exp=%~$where:1
if "%exp%" neq "" echo %exp%
goto :EOF
В скором времени эта тема превратится очередного кандидата на удаление из-за разразившегося флейма.
Можно всё время сравнивать разные технологии, но лучше ими пользоваться...
Ув. Модераторы, может перенесёте ветку в соответствующий раздел?
Некоторые, кто рискнул поиграться с PowerShell, заметили одну особенность: при дефолтных настройках не исполняются файлы скриптов, а если хочется использовать PowerShell как замену cmd.exe, то без подобной штуки становится очень тоскливо, Ведь не всегда нам работать с консолью в интерактивном режиме но конечно изменить уровень безопасности, но лучше пойти другим путём...
Работа с Windows PowerShell. Получение сертификата издателя программного обеспечения
По умолчанию, выполнение скриптов отключено. Различные политики (их всего 4) отвечают за возможность запуска как подписанных, так и неподписанных скриптов, которые могут быть как скачанными из Интернета, так и локальными.
Текущий уровень безопасности задаётся параметром «ExecutionPolicy» который, можно изменить в реестре. Он расположен по следующему пути:
Параметр «ExecutionPolicy» может принимать следующие значения:
AllSigned Все .ps1 и .ps1xml файлы должны иметь цифровую подпись. Это касается и конфигурационных файлов как для всей системы в целом, так и для конкретного пользователя. Если файл подписан и производится попытка его исполнения, то оболочка задаст вопрос о том, доверяете ли вы данному издателю и стоит ли запускать файлы, подписанные этим лицом (или организацией) в дальнейшем. Эта политика распространяется даже на файлы, которые созданы на вашей машине. Они тоже должны быть подписаны. Unrestricted Файлы могут не иметь цифровой подписи. Запуск файлов скачанных из сети будет сопровождаться предупреждающим сообщением. Для избавления от него необходимо выделить файл в explorer’е и нажав правую кнопку мыши выбрать пункт «Properties» (свойства) и нажать «Unblock»(разблокировать). RemoteSigned Файлы .ps1 и .ps1xml загруженные из сети с помощью программ Microsoft Outlook, Internet Explorer, Outlook Express или Windows Messenger и др. должны быть подписаны издателем, которому вы доверяете. Если файл имеет цифровую подпись и его попробовать запустить, то оболочка задаст вопрос о том, доверяете ли вы данному издателю и стоит ли запускать файлы, подписанные этим лицом или организацией в дальнейшем. Скрипты, которые являются локальными, запускаются без вывода запроса о доверии конкретному издателю и цифровой подписи не требуют. Restricted Исполнение скриптов запрещено. Данный запрет распространяется на системные и пользовательские файлы профилей. Данная политика включена по умолчанию. Загрузка конфигурационных файлов при старте возможна, однако они должны иметь цифровую подпись. В этом случае система спросит о возможности запуска сейчас и в дальнейшем скриптов подписанных этим лицом или организацией.
Сразу после установки в Windows PowerShell установлен режим Restricted, позволяющий работать с консолью только в интерактивном режиме. Посмотрим, что это нам даёт.
Сейчас у нас активна политика «по умолчанию» т.е. Restricted. Но поскольку файлы скриптов всё же запускать изредка необходимо, то придётся изменить её на AllSigned.
Windows(R) PowerShell
Copyright (C) 2006 Microsoft Corporation. All rights reserved.
PS C:\Program Files\Windows PowerShell\v1.0> cd c:\
PS C:\> Get-ExecutionPolicy
Restricted
PS C:\> Set-ExecutionPolicy AllSigned
PS C:\> Get-ExecutionPolicy
AllSigned
Для начала напишем самый простой пример. Пускай это будет уже избитое обращение к списку процессов.
В интерактивном режиме работы с консолью мы имеем право на выполнение команд. Попробуем запустить эту же команду из файла.
PS C:\> more test.ps1
Get-Process
PS C:\> .\test.ps1
The file C:\test.ps1 cannot be loaded. The file C:\test.ps1 is not digitally si
gned. The script will not execute on the system. Please see "get-help about_sig
ning" for more details..
At line:1 char:10
+ .\test.ps1 <<<<
PS C:\>
Как и ожидалось, нам погрозили пальцем. Ведь мы не имеем цифровой подписи. Ну что ж придётся её создать. Тем более, нам говорят, в каком направлении глядеть документацию.
PS C:\> get-help about_signing
Для того, что бы иметь возможность подписывать цифровой подписью скрипты, необходимо иметь соответствующий «сертификат». Они бывают двух типов: выданные третьей стороной – это компании вроде Verisign или Thawte и др. или самоподписанный сертификат. Конечно, если есть лишние финансы, то можно получить сертификат и у этих компаний. Но мы постараемся обойтись малой кровью – сделаем себе сертификат сами.
Для начала нам понадобится программа makecert.exe она входит в состав Microsoft .NET Framework SDK или Microsoft Windows Platform SDK. Так говорит встроенная справка в PowerShell, но данная программа включена и в Microsoft Office XP и лежит в папке
Русскоязычную справку по ключам программы можно посмотреть тут. Но есть небольшая оговорка – старые версии программы не поддерживают ключ -pe, а он нам понадобится для создания сертификата с экспортируемым приватным ключом. Затем мы его сохраним в хранилище сертификатов Windows. Поэтому нужно проверить поддерживает ли ваша версия этот ключ, если нет, то скачиваем makecert версии 5.131. Затем создаём сертификаты.
makecert -n "CN=PowerShell Local Certificate Root" -a sha1 -eku 1.3.6.1.5.5.7.3.3 -r -sv root.pvk root.cer -ss Root -sr localMachine
makecert -pe -n "CN=PowerShell User" -ss MY -a sha1 -eku 1.3.6.1.5.5.7.3.3 -iv root.pvk -ic root.cer
Результатом работы будут два файла: root.cer и root.pvk. Затем, из одного или нескольких сертификатов X.509 с помощью программы Cert2spc.exe производим создание сертификата издателя программного обеспечения (Software Publisher's Certificate, SPC).
cert2spc.exe root.cer root.spc
Результатом работы будет файл root.spc являющийся сертификатом издателя программного обеспечения (SPC). Затем необходимо конвертировать его в файл типа PFX.
Это файл обмена персональной информацией Personal Information Exchange (PFX), он защищён паролем. Вот его то нам и необходимо, в конечном счёте, получить. Для этого скачиваем программу pvkimprt
Microsoft Windows [Version 5.2.3790]
(C) Copyright 1985-2003 Microsoft Corp.
C:\WINDOWS>PVKIMPRT.EXE -pfx d:\Work\PowerShell\cert\root.spc d:\Work\PowerShell\cert\root.pvk
После этого, проверим удачно ли всё прошло.
PS C:\> dir cert:\CurrentUser\My -codesign
Directory: Microsoft.PowerShell.Security\Certificate::CurrentUser\My
Thumbprint Subject
---------- -------
3CA81DA6487CDF1631F862FBAB2F3D0CF9C3F69D CN=PowerShell User
Да, всё нормально. Остаётся только подписать наш файл. Для этого возьмём из справочного руководства готовый пример кода это осуществляющего.
## sign-file.ps1
## Sign a file
param([string] $file=$(throw "Please specify a filename."))
$cert = @(Get-ChildItem cert:\CurrentUser\My -codesigning)[0]
Set-AuthenticodeSignature $file $cert
Остаётся только в качестве переменной $file указать имя нашего файла. В результате получим файл следующего вида:
Get-Process
# SIG # Begin signature block
# MIIEMwYJKoZIhvcNAQcCoIIEJDCCBCACAQExCzAJBgUrDgMCGgUAMGkGCisGAQQB
# gjcCAQSgWzBZMDQGCisGAQQBgjcCAR4wJgIDAQAABBAfzDtgWUsITrck0sYpfvNR
Вырезано без потери для смысла
# EbkzcLgFVmeXsiGLpeEO2AzfUVbJdhltMBlEPo383U+l66eTAMDuFtQaVI2pgMcz
# cD2FEdSpU+PBojTim8ERjqvHKpTMIdQ=
# SIG # End signature block
Попробуем его запустить… Нас спросят доверяем ли мы этому издателю. Да, мы себе доверяем и разрешаем и в дальнейшем запускать скрипты подписанные этим издателем
PS C:\> .\test.ps1
Do you want to run software from this untrusted publisher?
The file C:\test.ps1 is published by CN=PowerShell User. This publisher is not
trusted on your system. Only run scripts from trusted publishers.
[V] Never run [D] Do not run [R] Run once [A] Always run [?] Help
(default is "D"):a
Handles NPM(K) PM(K) WS(K) VM(M) CPU(s) Id ProcessName
------- ------ ----- ----- ----- ------ -- -----------
171 5 5432 2572 41 0,62 3444 ccApp
288 6 3740 628 38 1,32 1576 ccEvtMgr
188 5 3552 832 31 0,92 1532 ccSetMgr
Однако если мы выложим свой подписанный файл в открытый доступ, и кто-то его скачает, то при включённой политике AllSigned он получит следующее предупреждение:
PS C:\ > .\ test.ps1
The file C:\ test.ps1 cannot be loaded. The signature of the
certificate can not be verified.
At line:1 char:11
+ .\ test.ps1 <<<<
Т.к. он подписан не вами. То и доверия к нему нет никакого. Поэтому придётся его просмотреть и если всё нормально, то подписать самим.
Особо дотошные личности спросят, а зачем дублировать посты с собственного блога life.screenshots.ru?
Ответ очень прост. Когда есть группа людей, которые интересуются одним и тем же, то нет необходимости каждый раз изобретать велосипед.
Сейчас уже доступна русская версия PowerShell RC2, но разделы справки они не обновоили, а потому некоторые вещи они в ней опустили... Можно скачать:
Версия для Windows XP SP2: ENRU
Версия для Windows 2003 SP1:ENRU
Здравствуйте, Severus, Вы писали:
S>PowerShell заменяет старую концепцию именования команд по типу выполняемых ими действий на новую, в которой команды имеют вид «действие-объект» (если на английском, то «Verb-Noun»). Глагол описывает действие (напр. get или set), а существительное — его цель (process или location). Стандартный набор глаголов перекрывает большинство задач (get, set, add, remove). Например, следующая команда возвращает информацию о системном времени: S>PS C:\> get-date S>9 октября 2006 г. 16:53:30
ужасный формат разве нельзя было делать без "-" ?.
скока алиасов придется делать
Здравствуйте, neFFy, Вы писали:
FF>Здравствуйте, Severus, Вы писали:
S>> Например, следующая команда возвращает информацию о системном времени: S>>PS C:\> get-date S>>9 октября 2006 г. 16:53:30
FF>ужасный формат разве нельзя было делать без "-" ?. FF>скока алиасов придется делать
Набираем Get-Alias и смотрим сколько нам придётся менять алиасов =)
PS> Get-Alias
А если серьёзно, то MS подумала о миграции юзеров.
Оболочка Windows PowerShell включает несколько переходных псевдонимов, которые позволяют пользователям Unix и Cmd использовать в Windows PowerShell знакомые им имена команд. В следующей далее таблице приведены наиболее часто используемые псевдонимы для команд Windows PowerShell, а также стандартные псевдонимы Windows PowerShell, если они имеются.
Команда CMD Команда Unix Команда PS Псевдоним PS
dir ls Get-ChildItem gci
cls clear Clear-Host (функция) Н/Д
del, erase, rmdir rm Remove-Item ri
copy cp Copy-Item ci
move mv Move-Item mi
rename mv Rename-Item rni
type cat Get-Content gc
cd cd Set-Location sl
md mkdir New-Item ni
Н/Д pushd Push-Location Н/Д
Н/Д popd Pop-Location Н/Д
В документации есть занятная глава:Создание объектов .NET и COM (командлет New-Object)...
Существуют программные компоненты с интерфейсами платформы .NET Framework и COM, которые позволяют выполнять множество задач системного администрирования. Оболочка Windows PowerShell позволяет использовать эти компоненты, поэтому задачи, которые могут быть выполнены, не ограничиваются только использованием командлетов. Ну и дальше по тексту.
К сожалению, мне не доводилось работать с .NET поэтому всё остальное — это следствие...
Нужно добавть пользователя на машину. Можно ли сделать это программно?
Конкретнее интересует вопрос какой класс использовать.
Например, для работы с XML я пользую
Ну и дальше вооружившись справкой можно что-либо делать по своему усмотрению.
Посмотрев на MSDN, я что-то с ходу не нашёл нужный класс. Может кто подскажет куда глядеть?
Прикольная штука, вот только на русской винде глючит
Первый же пример из документации: ipconfig | findstr "IP-адрес" ничего не возвращает.
А если написать просто "IP" — все сработает, но вместо русских букв будут знаки вопроса.
И такая же байда с dir и прочими командами, возвращающими русские имена.
Короче, findstr не обрабатывает русские буквы
Причем, и русский PowerShell и английский глючат одинаково.
если от LOCAL SYSTEM account'а будет запускаться процесс powershell.exe (допустим в связке cc.net-nant-powershell , то
запрос на запуск скрипта от untrusted publisher'а повиснет на заднем фоне...
Решается путём добавления PowerShell User'а след образом:
1. правый клик на user.cer (экспортируется из root.cer)
2. Install...
3. Next
4. Выбрать Place all sertificates in the following store
5. Browse...
6. Поставить галочку Show physical stores
7. Выбрать Trusted Publishers\Local Computer
...
Перекуём баги на фичи!
