Poznej IT Články Administrace -

H  Informatika  Počítačové sítě  Operační systémy  Programování  Administrace  Software  Databáze  Bezpečnost  Management  Technologie  Matematika  ALL

H  Informatika  Počítačové sítě  Operační systémy  Programování  Administrace  Software  Databáze  Bezpečnost  Management  Technologie  Matematika

Microsoft PowerShell

Seriál: Windows Powershell – úvod (část 1.)

PowerShell je skriptovací jazyk a shell od Microsoftu. Z předchozí věty jsem záměrně vypustil slovo nový, protože první verze byla vydána již v roce 2006. Verze 2 je v současné době ve stadiu CTP3 (Community Technology Preview) a její finální uvedení je plánováno současně s vydáním Windows 7.

Tato série si klade za cíl seznámit vás s PowerShellem od úplných základů až po složitější konstrukce. Nemá být (ani být nemůže) vyčerpávajícím zdrojem. Pokud se budete chtít PowerShell naučit, budete muset pokračovat dále, např. studiem nápovědy, která je až překvapivě dobrá a užitečná. Začněme instalací.

1.1 Instalace

PowerShell je součástí posledních verzí operačních systémů, tedy Windows 7 a Windows 2008 R2. Ve Windows 2008 je dostupný jako volitelný doplněk a můžete jej doinstalovat přes Server Manager. Pokud jej budete chtít použít ve Windows Vista, XP a 2003 Server, musíte si jej doinstalovat jako samostatné KB. Pro nižší verze není PowerShell dostupný. V současné době je možno PowerShell doinstalovat i přes Windows Update (nebo WSUS).

Před instalací PowerShellu se ujistěte, že máte nainstalován .NET Framework minimálně ve verzi 2.0. Výše zmiňované KB pak nainstalujete klasickým next, next, next způsobem. Po instalaci naleznete v nabídce Start složku Windows PowerShell 1.0 a v ní modrou ikonu, kterou si určitě zamilujete J

1.2 První krůčky

Po spuštění uvidíte následující modrou obrazovku – tato modrá (#012456) je dobrá.

Zkusme si ukázat první obligátní kus kódu – známý Hello World! V PowerShellu jej zapíšete následujícím jednoduchým příkazem:

PS C:\> “Hello World!”

PowerShell vezme váš vstup a text opíše na výstupu. Mimochodem, pěkný přehled Hello World programů můžete najít na Wikipedii. Pojďme si ukázat několik užitečnějších příkazů, např. pro zobrazení aktuálního data a času

PS C:\> Get-Date

3. června 2009 22:00:32

pracovního adresáře

PS C:\> Get-Location

Path 
—- 
C:\

nebo zjištění nastavení jazykového prostředí ve Windows.

PS C:\> Get-Culture

LCID Name DisplayName 
—- —- ———– 
1029 cs-CZ Czech (Czech Republic)

Chtěli byste například zpracovat v PowerShellu výsledky z vyhledávače Bing?

PS C:\> Get-BingWeb ‘technet powershell site:cz’ | Format-Table Url

url 
— 
http://www.logon.cz/?p=129 
http://www.wug.cz/Default.aspx?tabid=53&EntryID=75 
http://www.logon.cz/?tag=powershell 
http://www.wug.cz/Default.aspx?tabid=58&mid=500&ctl=Detail&ItemID=208&VisibleDate=1.12.2008 
http://blog.vyvojar.cz/dotnet/archive/2006/11/30/138593.aspx 
http://www.wug.cz/Default.aspx?tabid=53&EntryID=106 
http://www.wug.cz/Aktuality/tabid/36/ctl/Detail/mid/492/ItemId/270/language/cs-CZ/Default.aspx 
http://www.logon.cz/?p=230 
http://www.wug.cz/Default.aspx?tabid=58&mid=500&ctl=Detail&ItemID=144&VisibleDate=9.5.2008 
http://www.cs.vsb.cz/navrat/vyuka/sps/prednasky/pred10b.pdf

Příkaz vyhledá text „TechNet Powershell“ v českých doménách a pomocí Format-Table vypíše adresy prvních deseti odkazů, které nalezne.Get-BingWeb není standardním příkazem PowerShellu, ale je na něm ukázána jedna ze silných stránek PowerShellu – komunita. Již druhý den po ohlášení nového vyhledávače vytvořil Joe Pruitt knihovnu funkcí pro práci s bingem (PoshBing) a uvolnil ji pro veřejné použití. Pokud ji chcete také vyzkoušet, je ke stažení na CodePlexu.

1.3 Základní pojmy

Než se pustíme do podrobnějšího přehledu, řekneme si něco o terminologii v PowerShellu. Jedná se o základní poučky, které vám umožní začít PowerShell efektivněji a rychleji používat.

1.3.1 Cmdlet

Je základním příkazem PowerShellu. Vyslovuje se jako command-let. Ve verzi 1 je jich v PowerShellu 129. V příkladech výše jsme si ukázali cmdlety Get-Date, Get-Location a Get-Culture.

1.3.2 Jmenná konvence

V předchozím bodě jsme si ukázali tři cmdlety. Nezdá se vám na jejich jméně něco zajímavého? Pokud vám přijde zajímavá konvence Get-<něco>, jste na správné stopě. Vývojový tým PowerShellu zavedl jmennou konvenci, která je v angličtině vyjádřena jako Verb-Noun, čili v češtině Sloveso-PodstatnéJméno. Zároveň se snaží (a dle mých zkušeností úspěšně) tuto konvenci prosadit. V současné době existuje malá skupina sloves pro cmdlety a je v hojné míře používána. Více se můžete dozvědět přímo v blogu vývojového týmu PowerShellu.

Seznam sloves ve verzi 1 je následující:

Pro podstatné jméno platí pravidlo, že musí být v jednotném čísle. Proto existuje cmdlet Get-QADUser a nikoli Get-QADUsers.

Velkou výhodou této snahy je možnost „odhadnout“ jméno cmdletu, který právě potřebujete. Z příkladů je to víceméně jasné: chcete-li zjistit aktuální datum, použijte Get-Date; chcete-li datum nastavit, použijte Set-Date.

Na základě předchozích řádek asi dokážete dát dohromady příkaz, kterým zjistíte běžící procesy – je to Get-Process.

1.4 Bezpečnost

Řekněme si ještě něco krátce k bezpečnosti PowerShellu. Microsoft se poučil z hrozeb, které ohrožovaly počítače pomocí skriptů ve VBS a jedním z kroků je, že skripty v PowerShellu (přípona PS1) jsou po nainstalování asociovány s poznámkovým blokem. Tím odpadá „náhodné“ spuštění destruktivního kódu pouhým dvojklikem.

Několik dalších bezpečnostních prvků si ukážeme na příkladu. Zkuste vytvořit textový soubor, který bude obsahovat pouze jednu řádku textu, na které bude zapsán cmdlet Get-Date. Uložte tento soubor jako skript.ps1. Spusťte PowerShell a přejděte v něm do adresáře s vytvořeným skriptem. Pro pohyb použijte příkaz cd, známý z cmd.exe. Následujícím příkazem zkuste skript spustit:

PS C:\Temp\PS> skript.ps1

The term ‘skript.ps1’ is not recognized as a cmdlet, function, operable program, or script file. Verify the term and try again.

At line:1 char:10

+ skript.ps1 <<<<

Narazili jste na další „bezpečnostní překážku“ – PowerShell vám neumožní spustit skripty z aktuálního adresáře, pokud napíšete pouze jejich jméno. Příkaz musíte napsat následujícím způsobem:

PS C:\Temp\PS> ./skript.ps1

File C:\Temp\PS\script.ps1 cannot be loaded because the execution of scripts is disabled on this system. Please see “get-help about_signing” for more details.

At line:1 char:2

+ & <<<< “C:\Temp\PS\script.ps1”

Skript se vám opět nespustil, ale chybové hlášení je jiné. Dalším krokem k zabezpečení počítače jsou bezpečnostní politiky (v angličtině Execution policies), které hlídají, zda jsou spouštěné skripty digitálně podepsány. Po nainstalování je nastavena politika Restricted. V tomto módu je umožněno zapisování příkazů přímo v okně PowerShellu, ale pokud chcete spustit skript, PowerShell vám v tom zabrání a zobrazí chybu.

Bezpečnostní politiky jsou celkem čtyři: Restricted, AllSigned, RemoteSigned, Unrestricted. Pokud ji chcete změnit, použijte příkaz Set-ExecutionPolicy a jako parametr použijte jméno jedné ze jmenovaných politik.

Set-ExecutionPolicy RemoteSigned

zajistí, že skripty stažené z internetu nebo doručené mailem budou spuštěny, ale pouze pokud jsou podepsány důvěryhodným certifikátem. Nyní už bez problému spustíte skript, který jste vytvořili.

PS C:\Temp\PS> ./skript.ps1

3. června 2009 23:31:26

Pokud se chcete o politikách dozvědět více, zkuste v PowerShellu spustit příkaz

Get-Help about_signing

Je vidět, že Microsoft se poučil z minulosti a již od začátku navrhl PowerShell i s ohledem na bezpečnost. Poslední krok je ale samozřejmě vždy na uživateli. Pokud změníte bezpečnostní politiku na Unrestricted, není chybou PowerShellu, že spustíte skript z neznámého zdroje a poškodíte svůj počítač, či celou síť.

Doporučení: Nechte na svých počítačích politiku nastavenou alespoň na RemoteSigned, vyhnete se tak mnoha případným problémům.

1.5 Nápověda

Velmi silnou stránkou PowerShellu je jeho nápověda. Již při instalaci se nainstalují tři zajímavé dokumenty: User Guide, Getting Started a Quick Reference. Dohromady se jedná asi o 150 stran doporučeníhodného čtení.

Další možností je nápověda vestavěná přímo uvnitř shellu, dostupná je pomocí příkazu Get-Help. Jako administrátoři máte možná snahu nápovědu zatracovat, podceňovat či vůbec tak nějak nenávidět. V tomto případě by to byla chyba. Nápověda je zpracována velice dobře a už se mnohokrát osvědčila.

Toto je základní výpis informace o vybraném cmdletu. Všimněte si posledních dvou řádek a jejich doporučení. Nejpodrobnější informace získáte pomocí přepínače –Full. Součástí nápovědy ke každému cmdletu je ukázka příkladů použití. Pokud použijete přepínače –Full nebo–Detailed, budou příklady zobrazeny na konci výpisu. Pokud chcete pouze výpis příkladů, použijte přepínač –Examples.

Get-Help Get-Date –Examples

V PowerShellu existuje ještě jeden typ nápovědy – tematická. Každé z témat popisuje použití některých částí PowerShellu, např. aritmetické operace, regulární výrazy, aliasy, atd. Seznam všech témat je zobrazen níže.

Dnes jsme si ukázali některé základní vlastnosti PowerShellu. Příště si povíme o objektech, rouře a provázanosti PowerShellu s .NET Frameworkem. Těšte se…

Seriál: Windows Powershell – objekty a roury (část 2.)

Důležité vlastnosti

Když někomu řeknete, aby vám vysvětlil výhody PowerShellu, většinou se dozvíte, že jednou z nich je objektová roura. Mechanismus roury už většina z vás asi použila (nebo jste o ní alespoň slyšeli), horší to už bude zřejmě s tou její objektovostí. Práce s objekty vychází z toho, že PowerShell je postavený na platformě .NET Framework (vzpomínáte si, když jsme si v první části, že bez .NETu PowerShell nenainstalujete?). V dnešní části si povíme právě o objektech a rouře. O .NETu si povíme příště.

Objekty

Začněme obecným vysvětlením principu objektů. Ti z Vás, kdo máte znalosti jakéhokoli objektového jazyka, můžete tuto část přeskočit. Rovnou se omlouvám některým .NET puristům – určité části budu záměrně zjednodušovat. Tento článek je psán z pohledu administrátora a (v tuto chvíli) není nutné vědět, co je například konstruktor.

Při svých prezentacích PowerShellu pro lidi zabývající se administrací systémů jsem zjistil, že některým z nich dělá problém pochopit základní princip. Ukazuji jim tedy analogii na lahvích různých tvarů a náplní. Při druhém vyprazdňování flašky s rumem je jim to již většinou jasné. Na stránky seriózního média, jakým bezesporu TechNet je, ovšem alkohol nepatří a tak se spokojíme s něčím méně kontroverzním. Upustíme od tradičních žárovek nebo aut a přeneseme si do objektů svět zvířat – budeme pracovat s objektem kočkovitá šelma.

Každý objekt si sebou nese sadu vlastností a metod (funkcí).V případě kočky mezi vlastnosti patří např. velikost, barva chlupů, barva očí, váha či oblíbené jídlo. Řeknu-li tedy, že máme kočku oranžové barvy s černými pruhy, váhou 250kg, velikostí XXXL, která pojídá s oblibou buvoly, bude vám jasné, že mluvím o tygrovi. Pokud taková kočka váží šest kilo, je tříbarevná, velikosti M, má ráda šunku a její oblíbené místo k válení je klávesnice mého notebooku, asi tušíte, kde byste takovou kočku hledali.

Stejně tak to je s objekty v počítačovém světě. Pokud se budeme bavit například o procesech jsou jejich vlastnostmi ProcessName,WorkingSet, StartTime nebo Id. Vlastnosti popisují určitý stav objektu v čase, pokud chcete takový stav změnit, použijete k tomu určené metody.

Kočka má například metody spát, jíst, značkovat, vrnět nebo plést se pod nohy. Pokud u kočky spustíte metodu spát, můžete se jít v klidu dívat na televizi (dokud nevyvoláte u kočky metodu probudit se, například otevřením dveří od ledničky). U procesů je to podobné (s tou výjimkou, že procesy naštěstí na ledničku nereagují), zavoláním určité metody změníme chování nebo stav procesu. Existují například metody Start(), Refresh() nebo Kill().

Všimněte si, že jsem za názvy metod psal kulaté závorky. Berte to jako mnemotechnickou pomůcku, pokud uvidíte při práci s objekty závorky, pracujete s metodou.

Objekty a objektový přístup obecně, mají jednu obrovskou výhodu. Relativně jednoduše s nimi dokážeme pracovat pomocí základních příkazů. Když jsme si šli vybírat do útulku objekt kočka, věděli jsme, že chceme určitou velikost, barvu, roztomilost a způsob chování (samozřejmě že to dopadlo úplně jinak, ale to nebyla chyba objektového přístupu, ale změny vstupních parametrů v okamžiku vstupu do místnosti plné mňoukajících koťátek). U procesů je to naštěstí exaktnější. Počítač vám běží pomalu a tak hledáte process, který zabírá nejvíc procesorového času či paměti a na ten se zaměříte. „Zmrzla“ vám určitá aplikace a tak hledáte process s jejím jménem, abyste ho ukončili, resp. zavolali nad oním procesem metodu Kill().

Některé z typů objektů (s jejich vlastnostmi a metodami) jsou vypsány v následující tabulce. Co je třída si řekneme na konci dnešního článku.

Přístup k vlastnostem a metodám objektů

Než si ukážeme jak přistupovat k vlastnostem a metodám objektů hromadně pomocí roury, ukážeme si, jak k nim přistupovat v případě jednoho objektu. V následujících ukázkách si nejdříve uložíme textový řetězec do proměnné ($text) a poté budeme přistupovat k jednotlivým vlastnostem a metodám.

Za chvíli si ukážeme, jak zjistit, které vlastnosti a metody lze pro konktétní typ objektu použít.

Tip: PowerShell podporuje doplňování příkazů pomocí klávesy tabulátor <Tab>. Pokud byste v předchozím příkladu napsali $te<Tab>.Le<Tab>, PowerShell zápis doplní na správnou formu ($text.Length). Tabulátorem můžete „cyklovat“ mezi možnými variantami – v případě, že napíšete pouze $text. (tečka je zde důležitá), můžete opakovaným použitím klávesy <Tab> procházet všechny dostupné vlastnosti a metody.

Další možností je doinstalovat nástroj PowerTab, který po stisknutí <Tab> zobrazí dostupné vlastnosti a metody přehledněji.

Roura

Mechanismus roury (v angličtině pipeline) se ve výpočetní technice používá od sedmdesátých let, kdy byla tato technika implementována do operačního systému UNIX. Její idea je geniálně jednoduchá: „Vezmi výstup jednoho příkazu a pomocí roury jej pošli na vstup příkazu dalšího.“ Roura se zapisuje pomocí znaku | a byla dostupná již v dřívějších verzích operačních systémů Microsoftu. V cmd.exe (nebo již v MS-DOSu) jste ji mohli bez problémů použít např. pro stránkování dlouhých výpisů:

C:\>dir /b /s *.txt | more

Výstup příkazu dir (seznam txt souborů) je poslán na vstup příkazu more, který zajistí zastavení výpisu po zaplnění obrazovky. V PowerShellu můžete rouru použít třeba takto:

PS C:\> dir *.ps1 | Sort -Property Length

Na výstupu příkazu dir jsou objekty (kolekce objektů) a každý z nich reprezentuje jeden soubor s příponou PS1. Tyto objekty jsou pomocí roury předány na vstup příkazu Sort, který je vezme a setřídí je podle vlastnosti Length. Na výstupu příkazu Sort máme tedy soubory PS1 seřazené podle velikosti (opět se zde nacházejí ve formě kolekce objektů, takže bychom je mohli další rourou poslat jinému příkazu). PowerShell ví, že vlastnost Length je číselný údaj a že s ním má tedy jako s číslem pracovat. Stejně tak ví, že když napíšeme

PS C:\> dir *.ps1 | Sort -Property LastWriteTime

chceme řadit soubory podle časového údaje a sám provede potřebné úkony. Pokud tedy pracujeme s objekty v rouře, stačí vědět, kterou vlastnost potřebujeme pro dosažení potřebných výsledků.

Pojďme si ukázat ještě pár jednoduchých příkladů a potom si řekneme, jak vlastně zjistíme, které vlastnosti obsahuje konktétní typ objektu.

U posledního příkladu je dobré si uvědomit jednu věc – PowerShell najde všechny procesy, které se jmenují notepad a pošle je rourou dále. Stop-Process převezme opět všechny procesy a zastaví je. Pokud byste se překlepli a provedli následující příkaz (nezkoušet!!!)

Get-Process | Stop-Process

způsobili byste svému počítači (s Windows XP) modrou smrt, protože byste zastavili všechny běžící procesy. Abyste takovým věcem zabránili, existují v PowerShellu příkazy a přepínače, které si ukážeme v některém z následujících článků.

Zjištění vlastností a metod objektu

Nyní si ukážeme, jak zjistit, které vlastnosti a metody obsahuje konkrétní objekt. V PowerShellu je k tomuto účelu cmdlet Get-Member. Bez přehánění můžu prohlásit, že to je nejužitečnější cmdlet, který existuje. Ukažme si jeho použití nejprve na jednoduchém řetězci znaků (výstup byl zkrácen).

Vidíte, že řetězec má jednu vlastnost (Length) a množství metod (ve skutečnosti je jich 35). Jak je použít jsme si ukázali před chvílí. Pojď me si zobrazit vlastnosti objektu typu soubor.

Zde vidíte, jak jsem zjistil, že existuje vlastnost LastWriteTime.

Get-Member je opravdu vynikající průzkumník a pomocník. Zvláště ze začátku jej budete používat velice často.

Ještě jednu věc je potřeba zmínit. Všechny objekty stejného typu (např. procesy) jsou odvozeny od tzv. třídy. Třída říká, jaké vlastnosti a metody bude objekt mít. Nemusíte si pamatovat, že proces (např. notepad.exe) je vlastně odvozen od třídy System.Diagnostics.Process. Je ale dobré vědět, kde tuto informaci hledat pro případ, že byste chtěli např. na MSDN hledat podrobnější informace o objektu. PříkazGet-Member vám tuto informaci zobrazí v první řádce výpisu.

Můžete také použít následující kus kódu (schválně jsem použil relativně složitý a nečitelný zápis – chci vás tím nalákat na další část, kde si povíme mimojiné o aliasech):

Příkaz dir můžete změnit za jakýkoli jiný, který vás zajímá. Chcete-li ověřit, že text „Ahoj“ je opravdu string, můžete použít

Seriál: Windows Powershell – roury a aliasy (část 3.)

Práce s objekty v rouře

V předchozím díle jsme si ukázali jak lze jednoduše pracovat s objekty v rouře. Až doposud jsme pracovali s celou kolekcí objektů (např. všechny procesy, které nám PowerShell vrátil). Nyní si ukážeme, jak filtrovat objekty dle potřeby.

Pro práci s objekty slouží následující cmdlety:

Na ty nejčastěji používané se nyní podíváme podrobněji.

ForEach-Object a Where-Object

Jsou určitě nejpoužívanějšími z „objektových“ cmdletů. ForEach-Object přijme všechny objekty z roury a provede nad nimi danou operaci.Where-Object přijme také všechny objekty z roury, ale k dalšímu zpracování pošle pouze ty, které splňují danou podmínku. Čili:

Zpracuje z WMI všechny logické disky a vypíše jejich jméno, popis a prázdné místo v gigabytech. Pokud by nás zajímaly pouze pevné disky, mohli byste použít Where-Object pro odfiltrování nepotřebných záznamů:

Pomocí Where-Object jsme určili, že chceme pouze disky, které mají DriveType rovno tři (což lze jednoduše vyhledat v MSDN).

Pokud se vám nelíbí zobrazení výsledku, můžete použít operátor formátování (-f):

Select-Object

Tento cmdlet slouží k definování vlastností, které chceme předávat dále rourou. Srovnejte například následující příkazy:

Select-Object vezme z objektu uvedené vlastnosti a pošle je dále rourou. Tento cmdlet je užitečný hlavně při exportech, např. při použitíExport-Clixml.

Poznámka: Možná si říkáte, proč nepoužít místo Select-Object např. Format-Table, když oba dávají stejné výsledky:

Slovo stejné bych měl dát do uvozovek. Rozdíl je v tom (zde se dopustím úmyslně zjednodušení), že Select-Object posílá rourou dál pořád objekty, kdežto Format-Table pouze zapisuje textovou informaci (!) na standardní výstup (zde konzole). Můžete si to vyzkoušet jednoduchým pokusem:

Ve druhém případě nebudou na výstupu žádná jména, protože Select-Object nemá na vstupu žádný objekt.

Sort-Object

Často se stane, že potřebujete zjistit např. největší soubory v adresáři nebo procesy, které nejvíce zatěžují počítač. V těchto případech se hodí cmdlet Sort-Object. Některé příklady jsem uváděl v předchozím díle a proto je nyní pouze krátce připomenu:

Zde jsme seřadili procesy podle využití fyzické paměti (sestupně) a pět největších žroutů jsme vypsali.

Measure-Object

Potřebujete statistiku vašich skriptů? Measure-Object je vhodným kandidátem:

Group-Object

Tento cmdlet se vám bude hodit, pokud chcete například zjistit počet souborů v adresáři podle typu:

Compare-Object

Často se stane, že potřebujete porovnat určitý stav v čase. Nedávno jsem například řešil porovnání členství ve skupinách v AD. Jednoduše si porovnání můžete vyzkoušet následujícím způsobem:

Zde jsme si do proměnné $a uložili počáteční stav běžících procesů. Poté jsme spustili Notepad a do proměnné $b jsme uložili aktuální stav. Pomocí Compare-Object jsme oba stavy porovnali a ve výpisu je vidět rozdíl. Takovýmto jednoduchým způsobem můžete například dělat audit na vašem serveru.

Hezký skript, jehož středem je Compare-Object, je například k nalezení v článku Compare AD against snapshots od Dmitryho Sotnikova(PowerShell MVP).

New-Object, Tee-Object

Tyto dva cmdlety asi nebudete ze začátku moc používat, ale jelikož patří do skupiny s ostatními alespoň se o nich zmíním.

New-Object slouží k vytváření vlastních objektů. Pokud máte například organizační strukturu, se kterou chcete pracovat v PowerShellu, není nic jednoduššího než si pro každého člověka vytvořit objekt a poté s nimi pracovat v rouře.

Zde proměnná $companyStructure obsahuje seznam lidí ve firmě (vytvořený pomocí New-Object). Dále je již práce stejná jako se všemi dalšími objekty.

Tee-Object se používá uprostřed roury, pokud chcete „uschovat“ aktuální stav objektů a zároveň je poslat do další roury.

Na výstupu je pouze pět objektů, ale v souboru psid.txt jsou všechny objekty řazené podle Id.

Aliasy

V minulém díle jsem v posledním příkladu slíbil, že se dnes podíváme na aliasy. Alias můžeme chápat jako „zkratku“ při zápisu příkazů. Například

můžeme pomocí aliasu přepsat jako

Pokud jste v PowerShellu někdy zkusili příkaz dir, použili jste vlastně cmdlet Get-ChildItem. Seznam všech dostupných aliasů, můžete vypsat pomocí cmdletu Get-Alias.

Pokud chcete použít opačnou cestu, tedy zjistit všechny aliasy pro daný cmdlet, můžete použít následující příkaz. Ukážeme si v něm aliasy pro cmdlety, které jsme probírali v předchozí kapitole.

Vypíšeme všehny aliasy a pomocí Where-Object vyfiltrujeme pouze ty, které splňují naše podmínky. Výsledky pak pomocí Format-Tablepřehledně vypíšeme. Předchozí příklad můžeme přepsat pomocí aliasů následovně:

WTH? Zde jsem se úmyslně vrhl do absolutních obskurností. Takový zápis byste asi nikde vidět neměli. Chtěl jsem ukázat nebezpečí aliasů (a dalších „zkracovačů“). Pokud to přeženete, těžko se ve výsledku vyznáte. Na aliasy existují rozporuplné názory – někdo je nepoužívá vůbec, někdo částečně a někdo se v nich vyžívá. Zde bych asi doporučil obecně uznávané pravidlo. Ve skriptech používejte celé jméno, v konzoli se aliasům nebraňte (ale samozřejmě platí – používejte to, co nejvíce vyhovuje vám).

Powershell seriál – dolujeme data aneb jak na WMI (část 4.)

Než začneme s dnešní dávkou informací, chtěl bych se zmínit o změně, která se udála ve světě PowerShellu od vydání posledního dílu tohoto seriálu. 27.října byl uvolněn PowerShell v2 pro platformy Windows XP a Windows Server 2003 a nyní je tedy nová verze PowerShellu dostupná pro všechny hlavní platformy od Microsoftu. PowerShell v2 můžete (a vřele vám to doporučuji) stahovat zhttp://support.microsoft.com/kb/968929 Vzhledem k této změně budu od tohoto dílu používat pro všechny příklady novou verzi. Zrovna u WMI se nám to bude velice hodit J

WMI (Windows Management Instrumentation) – technologie vynikající, leč – bohužel – částí administrátorů nenáviděná nebo (!) nepoznaná. Pro potřeby tohoto článku se spokojíme se zjednodušenou definicí, že WMI je technologie sloužící ke správě Windows systémů. Pokud byste se chtěli dozvědět víc, zkuste například mé oblíbené MSDN: http://msdn.microsoft.com/en-us/library/aa394582(VS.85).aspx

Pro potřeby tohoto článku budu předpokládat, že znáte základní informace o WMI a že víte, co je třída, vlastnost, WQL nebo instance.

1.1 Jak získat data z WMI

Náš hlavní kamarád pro dnešek bude gwmi – co to asi může být? Jedná se o alias – malý test, jestli si pamatujete minulý díl 

Get-WmiObject je – dle mého názoru – základním příkazem pro práci s WMI v PowerShellu. Ve v1 byl pouze tento cmdlet. Ve v2 jsou navíc tyto cmdlety: Invoke-WmiMethod, Remove-WmiObject, Register-WmiEvent, Set-WmiInstance.

Pojďme si ukázat základní použití cmdletu Get-WmiObject. Potřebujeme například zjistit typ našeho počítače:

Jednoduché, efektivní. Pokud jste někdy pracovali s WMI ve VB Scriptu, musí vám předchozí příklad připadat jako zázrak. Ve VBS bylá práce s WMI – řekněme – trochu komplikovaná (já osobně jsem do WMI přistupoval s lehkým odporem). S PowerShellem se situace změnila. Get-WmiObject je prostě dar z nebes (možná trochu přeháním, ale vzhledem k tomu, že s WMI pracuji každý den, vím, o čem mluvím).

Při práci s WMI vás budou asi nejvíce zajímat třídy, jejichž jméno začíná na Win32. Můžeme si je vypsat tímto příkazem:

Nebudu zde vypisovat všechny vrácené třídy, zkuste si je vypsat sami. Na mém počítači jich je 476. Zajímavé jsou například (kromě již zmíněné Win32_ComputerSystem) i Win32_OperatingSystem, Win32_Product nebo Win32_QuickFixEngineering (+ dalších asi 20, které budete používat nejčastěji, ale zkuste je najít sami – každému bude vyhovovat něco jiného dle zaměření). Pojďme si ukázat ještě jeden krátký příklad a poté se podíváme na složitější konstrukce. Bude nás zajímat verze operačního systému a service pack.

1.2 Parametry cmdletu Get-WmiObject

Jeden z prvních parametrů, který určitě využijete je –computername. Již v PowerShellu v1 bylo možné je připojit na vzdálený počítač a zjistit informace z WMI. Stačilo použít právě tento parametr. Pokud si například chcete udělat inventuru instalovaný service packů na vaší síti, stačí použít následující příklad:

Daleko efektivnější než psát jména počítačů do konzole bude zřejmě čtení z textového souboru, takže náš příklad upravíme následovně:

Při čtení některé z objemnějších tříd v WMI je lepší využít některý z následujcích parametrů: Filter nebo Query. Důvody jsou dva – rychlost zpracování a objem přenášených dat (ve spojení s parametrem ComputerName). Ukážeme si tři různé přístupy k získání požadovaných informací a povíme si o jejich výhodách a nevýhodách. Úkolem bude zjistit, jestli máme na počítači nainstalován produkt PowerGUI (mimochodem vynikající, volně dostupný editor na PowerShell).

Pro zjištění instalovaných programů použijeme třídu Win32_Product. Prvním vaším nápadem bude možná útok „hrubou silou“ – gwmi Win32_Product – v záplavě ujíždějících obrazovek si poté zpětně najdete (nebo nenajdete) požadovanou informaci. Toto je samozřejmě cesta, ale pro naše potřeby ji budeme považovat za nevhodnou (i když někdy je tento styl to nejrychlejší, co v praxi máte).

Jako další by vás mohlo napadnout použít filtrování objektů z minulého dílu a použít Where-Object.

V tomto případě by se nám měl vrátit záznam pouze pro zmiňované PowerGUI. Tato metoda není špatná, ale má jednu vadu. PowerShell vznese dotaz do WMI, dostane zpět všechna data z třídy Win32_Product a poté je pomocí cmdletu Where-Object filtruje na základě našeho požadavku. Problém máme právě s oním slůvkem „všechno“. Objekty opravdu filtrujeme až na úrovni PowerShellu, což není úplně efektivní. Lepší je, pokud filtrujeme data přímo na úrovni WMI (čímž zrychlujeme provádění dotazu). Zpátky se nám pak vrátí pouze data splňující zadanou podmínku. Což v případě přístupu na vzdálený počítač snižuje zatížení sítě. Použijeme tedy parametr Filter.

Nyní jsme přenesli filtrování dovnitř WMI a zpět se nám vrací pouze data spňující podmínku uvnitř filtru. Zde již potřebujeme alespoň základní znalosti WQL (http://msdn.microsoft.com/en-us/library/aa394606(VS.85).aspx). Pokud chceme mít úplnou kontrolu nad filtrováním, můžeme použít parametr Query a příklad přepsat následujícím způsobem.

Nyní jsme použili kompletní dotaz pomocí WQL. Uvědomte si, že vše, co se nám vrací je opět objekt a proto můžeme použít například následující konstrukci:

Pokud se chcete podívat na srovnání rychlosti zmiňovaných přístupů, podívejte se například na http://powershell-cz.blogspot.com/2009/08/ziskavani-informaci-z-wmi.html

Osobně používám Get-WmiObject velmi často, a většinou používám buď první (hrubá síla) nebo poslední (Query) přístup. Při použití obou přístupů většinou ukládám vrácené objekty do proměnné, se kterou dále pracuji.

1.3 Parametr AsJob

V PowerShellu v2 se objevila (mimojiné) možnost spouštět cmdlety na pozadí. Toto je obrovská výhoda při spouštění příkazů, které trvají dlouhou dobu. Můžete si běh příkazu přepnout do pozadí a dále pracovat v konzoli bez jejího blokování běžícím příkazem. Pokud budeme chtít poslední příkaz vylepšit, použijeme tedy

Dotaz do WMI se přesune na pozadí a okamžitě se objeví příkazový řádek. Můžete pracovat dále a za chvíli zjistit stav běžícího dotazu pomocí cmdletu Get-Job.

Je vidět, že job nám ještě stále běží. Pokud skončí, uvidíte následující výsledek:

State je nyní Completed a proto si můžeme zobrazit výsledek

Receive-Job přináší jedno nebezpečí. V případě, že jej použijete, jak bylo naznačeno, data obdržíte zpět, ale pokud si je neuložíte, znovu už je nezískáte. Zkuste zavolat příkaz znovu a uvidíte. Máte dvě možnosti: 1) uložit si výstup cmdletu Receive-Job do proměnné nebo 2) zavolat Receive-Job s parametrem –Keep.

Závěrem jedna malá odbočka k testovanému PowerGUI. Pokud se chcete podívat, jak přistupovat do WMI přes PowerGUI, stáhněte si tento produkt z www.powergui.org a prozkoumejte větev WMI Browser. Vynikajícím zdrojem pro průzkum WMI z PowerShellu je také WMI Explorer on /\/\o\/\/a.

Dnes jsme se lehce podívali na jednu novinku v PowerShellu v2 – joby. Vzhledem k tomu, že verze 2 je nyní standard budu ji v dalších dílech využívat vice. Po plánovaném posledním díle se zaměříme na novinky, které nám – administrátorům – výrazně ulehčují nebo zrychllují práci.

Seriál: Windows Powershell – souborový systém a registry (část 5.)

Po minulém díle, kdy jsme se podívali do hloubi systému si dnes dáme trochu oddechovější část – práci se souborovým systémem a registrem. Nejdříve se ale podíváme na ideu takzvaných PSDrives.

„Vše je drive.“ By mohla znít parafráze známého „vše je soubor“.

Již ve verzi 1 PowerShellu byly PSDrives zavedeny. Jedná se o snahu jak zjednodušit přístup ke stejným/podobným částem systému tak, abyste je již jednou naučenou věc nemuseli učit znovu. Jako příklad porovnáme souborový systém a registr. Vžíjte se do doby středověku Windows (tedy doby, kdy ještě neexistoval PowerShell). Pokud pomineme Windows Explorer a Registry Editor (ale jako administrátoři jste je stejně nepoužívali), mohli jste použít cmd.exe a reg.exe. Oba dva příkazy určitě znáte, ale dovolím si tvrdit, že reg.exe používáte velmi málo už jen z toho důvodu, že jeho syntaxe je „prostě jiná“ (netvrdím, že REG QUERY používám každý den 100x – regedit vede na celé čáře). PSDrives přináší výhodu v tom, že se zbavujeme onoho „prostě jiná“ a pohybujeme se v registru (ale nejen tam, jak uvidíme vzápětí) pomocí příkazů známých z cmd.exe. Čili převedeno do řeči PowerShellu, jestliže vím, že příkazem

Vylistuji obsah adresáře, můžu příkazem

Vylistovat obsah registru. A co teprve zábava s příkazem

Který zobrazí certifikáty. Chcete-li zjistit, co vše je vlastně PSDrive, můžete zkusit cmdlet Get-PSDrive (případně tématickou nápavěduabout_Providers). Měli byste vidět minimálně následující seznam:

Pokud používáte PowerShell v1, nebudete mít v seznamu poslední položku (WsMan). Nyní vidíte, proč jsem mohl použít dir hklm: a dir cert: – stejným způsobem můžete prozkoumat například aliasy nebo funkce. Určitě se vám bude hodit náhrada za příkaz set, zkuste

Základy souborového systému

Ukážeme si nyní základní příkazy pro pohyb a práci v souborovém systému (a tedy i ostatních PSDrives). Souborový systém volím z toho důvodu, že je asi nejnázornější pro výklad.

Základem jsou příkazy známé již od dob MS-DOSu (dir, cd, copy, …) nebo například z lixových OS (ls, man, …). V PowerShellu jsou tyto příkazy definovány jako aliasy, např. dir je alias pro Get-ChildItem. Vyzkoušejte si příkazy, které znáte z cmd.exe, a zkuste vypátrat jejich cmdlety. Můžete samozřejmě hledat i cmdlety pro příkazy copy, move, rm, … Brzy zjistíte, že končí slovem item, čili můžete vyzkoušet

U většiny z nich není asi potřeba něco dodávat. Trošku výjimečným případem je Invoke-Item, který spustí defaultní akci nad volaným objektem (např. otevře textový soubor v editoru), čili

vytvoří textový soubor, naplní jej zadaným textem a poté jej otevře v editoru, který je nastaven jako primární pro otevírání textových souborů. Na mém počítači je výstupem toto okno:

1.3 Práce s ACL

Při mých prezentacích pro administrátory sklízí asi největší obdiv příkazy pro práci s ACL. Vždy je ukazuji na následujícím příkladu. Máme za úkol vytvořit adresářovou strukturu pro nově vzniklá oddělení. Potřebujeme adresáře od písmena A do Z a pro tyto adresáře musíme nastavit předem daná práva (různá dle oddělení). V Exploreru noční můra, v PowerShellu zábava. Všimněte si i použítí ostatních cmdletů určených pro práci s PSDrives.

Chcete-li více informací k tomuto příkladu i celé prezentaci, můžete se podívat na tento příspěvek.

Pokud spravujete file server, určitě se vám budou cmdlety Get-Acl a Set-Acl hodit. Vzhledem k tomu, že je můžete využívat v rouře stanou se vám určitě výtanými pomocníky. Nezapomeňte na PSDrives – oba dva příkazy můžete použít také pro práci s registry.

Registr

Jelikož cmdlety pro práci s registry jsou stejné jako pro práci se souborovým systémem, podíváme se rovnou na jedno úskalí. Při práci s registry nás čeká jedno nepříjemné překvapení. Zkusme:

Místo očekávaného seznamu programů spouštěných při startu systému dostáváme jakýsi zvláštní, nicneříkající výpis. Pokud chceme zjistit požadované informace, musíme použít jiný cmdlet – hodnoty v určitém klíči jsou totiž považovány za vlastnosti tohoto klíče (v našem případě větev Run). Použijeme proto Get-ItemProperty a výsledkem bude očekávaný výstup

Jelikož pracujeme opět s objekty, není problém získat konkrétní hodnotu nějakého klíče

Další PSDrives

Jak by se vám líbilo, kdybyste mohli požít následující příkaz:

PS C:\> cd ad:

Zde parazituji na názvu jiného článku (http://www.jonathanmedd.net/2009/11/cd-ad-wow.html), ale asi tušíte, co vás čeká. Přístup do Active Directory přes PSDrives a práce s účty podobná jako se soubory. Pokud vás práce v AD před PowerShell zajímá více, měli byste věnovat svou pozornost tomuto blogu. Pokud ještě nemáte doménu s Windows 2008 R2 serverem nebo nepoužíváte Active Directory Management Gateway Service, můžete použít PSCX, které PSDrive pro Active Directory také obsahují.

Pro administrátory SQL Serveru 2008 není například neznámý PSDrive SQLSERVER.

Seriál: Windows Powershell – PS pro programátory (část 6.)

Na Technet Flash běží už několikátý díl o skriptovacím nástroji zvaném PowerShell, kterým provází David Moravec. Seznámili jsme se se základy PowerShellu a dotknuli se i pokročilejších témat jako jsou WMI anebo PsDrives.

PowerShell byl navrhnutý primárně pro administrátory, kteří dostali do rukou konečně rozumný nástroj umožňující zautomatizovat jim jejich postupy. Proto jej Microsoft integruje například do Windows Serveru 2008, nebo do SQL Serveru 2008. Vznikají i další knihovny – na správu IIS, Exchange, VmWare, atd.

Proč by ale PowerShell neměl dostat šanci i u programátorů, nebo pokročilých uživatelů Windows? Pokud jste někdy tvořili .bat soubor, nebo se snažili o „skriptování“ v klasické windows command line, bude PowerShell určitě správnou volbou. Jeho syntaxe je daleko příjemnější, více příbuzná běžným programovacím jazykům. Krom toho disponuje i velmi zajímavými příkazy (cmdlety) přímo integrovanými do jádra.

Tento článek má být určen především programátorům. Budu se zde snažit nastínit některé tipy, které jim mohou usnadnit práci.

Automatické zpracování

Jako první asi zdůrazním tu základní věc, proč PowerShell získal takovou oblibu – velmi jednoduše můžeme vyřešit úlohu, kterou bychom museli jinak psát například v C#. Co znamená “jednoduše”? Jediné, co musíte udělat, je vytvořit si ps1 soubor a tento spustit v PowerShell konzoli. (samozřejmě bychom se obešli i bez souboru, ale takto si postupně můžeme tvořit knihovnu užitečných skriptů)

Jak bychom to dělali jinak? Ve Visual Studiu bychom vytvořili C# command line projekt a do přislušné vygenerované Main metody bychom začali psát kód. Parsování předaných argumentů, procházení souborů, adresářů, operace nad nimi, práce s chybovými stavy atd. Přeložit, spustit a máme výsledný exe soubor. Na jednoduchou úlohu je toto příliš zdlouhavé a množství vygenerovaných souborů je velké (i případě, že bychom pouze překládali pomocí csc, počet souborů je dvojnásobný).

C# se hodí na komplexní zpracování, kde využijeme jeho aspektů. Už jen code noise je u C# ve srovnání s PowerShellem obrovský. Jakýkoliv úkol proveditelný z .NETu, se dá zpracovat pomocí PowerShellu. Typickým úkolem může být: projdi všechny soubory v daném adresáři, otevři je a nahraď řetězec XYZ řetězcem ABC.

Samozřejmě se nemusíme omezovat jen na nahrazování. Nedávno jsem viděl člověka, který řešil duplicitu u svých fotek. Na disku měl velmi mnoho fotografií a některé byly v různých složkách vícekrát. Jeho přáním pak bylo najít ty fotografie, které jsou stejné. Přitom bylo potřeba u nich ignorovat i Exif – některé totiž byly s Exifem, jiné bez. Můžete se podívat na daný dotaz.

Jinak pro jednu velmi jednoduchou ukázku si můžeme roztřídit fotografie podle toho, jestli jsou navysoko, nebo naležato. Výsledek si pak seřadíme podle orientace a jména. Fotografie mohou být v adresáři libovolně hluboko zanořené:

$d = gci D:\temp\ dscn*.jpg -rec |

% {

$b = new-object System.Drawing.Bitmap $_.FullName

New-Object PsObject -prop @{

Orientation=if($b.Height -gt $b.Width) { ‘v’ } else {‘h’ };

Path=$_.fullname }

$b.Dispose()

} |

sort -Property Orientation,Path

Kód by se dal ještě zkrátit nevytvářením objektu, ale už by to bylo případně na úkor čitelnosti. 
Podobných úloh pak můžeme najít mnoho, stačí zapojit svou fantazii. Dále už budu mluvit o konkrétních technikách a vlastnostech PowerShellu.

Práce s XML

Jedna z věcí, která se vám zalíbí, je práce s XML. Představte si, že se na celý XML soubor podíváme jako na objekt – z atributů se stanou stringové property a z vnořených elementů se stanou složené property objektu. Leckoho asi napadne (de)serializace. V tomto případě sice o deserializaci nejde, ale výsledek je podobný. Při deserializaci je vytvořen objekt určitého typu, zatímco při načtení xml v PowerShellu dostaneme k dispozici objekt typu XmlDocument, který je všem programátorům v .NET dobře známý.

Vezměme si příklad. Nejdřív si vytvoříme testovací xml soubor.

PS> @”

<root>

<article date=”2010-12-01″>

<name>Discover new dimensions</name>

<body>Discover them now. Go!</body>

</article>

<article date=”2000-01-01″>

<name>Future</name>

<body>what will be with us in ten years?</body>

</article>

</root>

“@ | Set-Content c:\temp\flashtest.xml

Zkusíme soubor načíst a přetypovat na xml (jde o použití tzv. accelerátoru) a podívat se, co se nám vlastně vrátilo.

PS>$x = [xml](gc c:\temp\flashtest.xml)

PS>$node = $x.root.article | ? { [datetime]$_.date -lt [datetime]’2005-01-01′ }

PS>$node

date         name                     body

—-         —-                     —-

2000-01-01   Future                   what will be with us in ten years?

PS>$node.name = ‘Near ‘ + $node.name

PS>$x.root.article[0].date = (get-date).ToString(‘yyyy-MM-dd’)

Pomocí tečkové notace známé snad všem programátorům přistupujeme k jednotlivým elementům. Proměnná $x je typu XmlDocument, zatímco $node je typu XmlElement. Nastavení nové hodnoty atributu, nebo testového elementu probíhá jednoduchým přiřazením. Přidávání elementů je již plně v režii .NET.

PS>$note = $x.CreateElement(‘note’)

PS>$note.InnerText = ‘poor content’

PS>$node.AppendChild($note)

PS>$x.root.article[1]

date        name             body                                note

—-        —-             —-                                —-

2000-01-01  Near Future      what will be with us in ten years?  poor content

Vybírat elementy pomocí XPath šlo dříve opět jen pomocí .NETích prostředků, od verze 2 máme k dispozici cmdlet Select-Xml.

PS>Select-Xml -Xml $x -XPath ‘//article[contains(body/text(),”ten”)]’

PS>#použití namespace

PS>$ns = @{ e = “http://www.w3.org/1999/xhtml” }

PS>Select-Xml -Path $somePath -Xpath //e:div[@id] -names $ns

Jako zdroj pro Select-Xml můžeme použít nejen xml, ale i seznam cest k xml souborům, nebo xml ve formě řetězce (string).

Na uložení xml nemá PowerShell žádné speciální prostředky. Použijeme opět .NET volání:

PS>$x.Save(‘c:\temp\res.xml’)

Regex tester

V PowerShellu si můžete velmi rychle vyzkoušet své regulární výrazy. Nebudu zde popisovat, co je to regulární výraz, jak se tvoří a k čemu slouží. Více informací k regulárním výrazům nabízí například Regular-expressions.info. 
Místo vysvětlování základů se podíváme, jak můžeme rychle otestovat, zda regulární výraz “dělá to, co má”.

Jestliže máte po ruce konzoli PowerShellu, je toto snad nejrychlejší způsob (pozn. pokud se vám konzole špatně hledá mezi ostatními okny, možná vám pomůže AutoHotkey). Spouštět programy určené pro testování regulárních výrazů nebo si je zkoušet online vyžaduje režii, která programátora zpomalí. Jak uvidíme, PowerShell touto brzdou nebude. Podívejme se tedy, jak na to – pro testování regulárních výrazů je zde totiž několik přístupů.

Operátor -match

Nejjednodušším z nich je použití operátoru -match, kterému jako pravý operand předáme regulární výraz.

# hloupý regex jen pro účel demonstrace

PS>’jeho email je karel@novak.cz’ -match ‘ \w+@[a-zA-Z_]+\.(?<d>[a-zA-Z]{2,3})’

True

PS>$matches

Name                           Value

—-                           —–

d                              cz

0                              karel@novak.cz

V kolekci $matches nám PowerShell udržuje groupy z posledního vyhodnocení operátorem -match. Groupa 0 obsahuje celý řetězec, který regulárnímu výrazu odpovídá. Regulární výraz není case sensitive a v podstatě odpovídá regulárnímu výrazu bez jakýchkoliv speciálních options.

Pro případ, že potřebujeme mít test case-sensitive, použijeme operátor -cmatch.

Operátor -match také umí filtrovat pole řetězců. Vyzkoušejte si následující příklad a hned pochopíte:

PS>’1a’,’2b’,’1c’ -match ‘1\w’

PS>’1a’ -match ‘1\w’

Akcelerátor [regex]

Na vytvoření regulárního výrazu můžete použít akcelerátor [regex]:

PS>$r = [regex]’^\w+@[a-zA-Z_]+\.(?<d>[a-zA-Z]{2,3})$’

PS>$r.GetType().FullName

System.Text.RegularExpressions.Regex

Vytvoří se klasický .NET regulární výraz a uloží do proměnné $r. Opět zde nemá žádné zvláštní options, o čemž se můžeme přesvědčit takto:

PS>$r | fl

S regulárním výrazem pak pracujeme tak, jak známe – pokud bychom nevěděli, pak nám pomůže výpis metod a properties:

PS>$r | gm

TypeName: System.Text.RegularExpressions.Regex

Name                MemberType Definition

—-                ———- ———-

…

GetGroupNames       Method     string[] GetGroupNames()

GetGroupNumbers     Method     int[] GetGroupNumbers()

…

IsMatch             Method     bool IsMatch(string input), bool IsMatch(strin

Match               Method     System.Text.RegularExpressions.Match Match(st

Matches             Method     System.Text.RegularExpressions.MatchCollection

Replace             Method     string Replace(string input, string replacemen

…

Vytvoření objektu

Poslední možností, která ale úzce souvisí s druhou, je vytvoření regulárního výrazu pomocí cmdletu new-object. Zde pak můžeme specifikovat volby jako multiline, singleline apod.

PS>$opts = [System.Text.RegularExpressions.RegexOptions]’MultiLine,

SingleLine’

PS>$r = new-object Text.RegularExpressions ‘^\w+@[a-zA-Z_]+?\.(?<d>

[a-zA-Z]{2,3})$’,$opts

Povšimněte si zajímavé syntaxe, jak specifikovat options u regulárního výrazu – nenašel jsem ji pořádně v nápovědě popsanou. Pomohla mi pouze zmínku na blogu Using Enumerated types (Enums) in PowerShell.

Obecně se s enumy v PowerShellu pracuje hezky. Není nutné uvádět typ enumu, stačí pouze hodota ve stringové podobě. 
Navíc – zkuste si například toto:

PS>[string]::Compare(‘a’,’a’,[Globalization.CultureInfo]::CurrentCulture, 

‘test’)

Cannot convert argument “3”, with value: “test”….. The possible 

enumeration values are “None, IgnoreCase, IgnoreNonSpace, … Ordinal”.”

PS>[string]::Compare(‘a’,’a’,[Globalization.CultureInfo]::CurrentCulture,

‘IgnoreCase’)

PowerShell vám napoví, jaké hodnoty může enum nabývat – není tedy nutné hledat v dokumentaci. Výrazně se tím zrychlí vývoj.

Pozn.: Samozřejmě můžeme použít i statické metody třídy [regex], které se volají pomocí dvojtečky:

PS>[regex]::IsMatch(‘karel@novak.cz’, ‘^\w+@[a-zA-Z_]+\.(?<d>[a-zA-Z]{2,3})$’)

Pozn. 2: Krom operátoru -match je vhodné znát i operátor -replace, který slouží k nahrazování textu. Velmi jednoduché a účinné nahrazení textu v souboru můžeme dosáhnout takto:

PS>(Get-Content c:\test.txt) -replace ‘abc’,’def’ | Set-Content c:\test.txt

Metoda FindR

Později v sekci o clipboardu využívám metodu FindR. Jde o funkci, která filtruje vstupní data podle zadaného regulárního výrazu.

filter FindR($regex) {

[Regex]::Matches($_, $regex, ‘IgnoreCase’) | % { $_.Value }

}

Jako data můžeme poslat prakticky cokoliv. PowerShell se poté snažit vstup konvertovat na string, protože metoda Matches očekává string. Pokud do pipeline posíláme objekty, PowerShell runtime se rozhodne sám, jak objekt zkonvertuje na string.

Tak například dir | findr ‘.*gs.*’ nám bude fungovat, ale bude vracet pouze jména souborů/adresářů.

Ale Get-WinEvent -LogName Application -MaxEvents 10 | findr ‘.*instal.*’ nezafunguje, protože jako vstup do metody MatchesPowerShell vloží řetězec ‘System.Diagnostics.Eventing.Reader.EventLogRecord’. Tuto hodnotu zřejmě získal prostým zavolánímToString() na objektech z Get-WinEvent.

Reálné použití si sami jistě dokážete vymyslet. Já jej sem tam používám na práci s logy od zákazníků. Naposledy jsem filtr použil, když jsem zkoumal log, který se týkal importu souborů. V logu byly zapsány jejich velikosti a já jsem potřeboval zjistit jejich průměrnou velikost a celkový součet. Na vyparsování konkrétních velikostí je použit look behind.

gc c:\dev\WO\\wpdataimport.log |

findr -r ‘(?<=Job content file size: )\d+’ |

Measure-Object -Sum -Average

První příkaz načte soubor, druhý profiltruje jeho řádky a vrátí řetězce (číslice), před kterými je “Job content file size: ” a poslední příkaz sečte čísla (zkonvertuje řetězce na čísla) a spočítá jejich průměr.

Kódování, dekódování, konverze, …

Obzvláště weboví vývojáři někdy potřebují pracovat s base64 stringy, případně kódovat a dekódovat url. Samozřejmě na konverzi existují dostupné nástroje. Jednodušší ale je přímo do PowerShell profilu přidat příslušné funkce, takže budou vždy velmi rychle dostupné.

# načte assembly potřebnou pro práci s url (pokud ještě načtená nebyla)

Add-Type -AssemblyName System.Web

Ti kteří často pracují v PowerShellu pak mohou ocenit například takovou funkci:

PS> function Run-GoogleQuery {

param([string]$word)

Start-Process (‘http://www.google.cz/search?q=’ + (UrlEncode $word))

}

PS> Set-Alias qg Run-GoogleQuery

PS> qg ‘toto je test’ # spustí defaultní browser s dotazem na google

Konverzi HtmlEncode jsem například využil při psaní tohoto článku, když jsem potřeboval vložit PowerShell kód a zakódovat korektně HTML znaky. 
S využitím funkce clip (kterou uvedu později v sekci o clipboardu) to bylo vcelku jednoduché:

HtmlEncode (clip) | clip

(znamená to: vezmi obsah schránky, zakóduj a vlož do schránky)

Převod Html2Xml

Někdy se hodí i převod html na xml. V tomto případě využijeme volně dostupnou assembly SgmlReader.

function Convert-Html2Xml {

param(

[Parameter(ValueFromPipeline=$true)][object[]]$html

)

begin   { $sb = new-object Text.StringBuilder(20kb) }

process { $html | % { $null = $sb.AppendLine($_) } }

end {

# udelame si zivot jednodussi…

$str = $sb.ToString().Replace(‘ xmlns=”http://www.w3.org/1999/xhtml”‘, ”)

Add-Type -Path G:\bin\SgmlReaderDll.dll

Máme pak dva způsoby, jak volat:

PS>$x1 = gc c:\temp\testhtmlsource.delete.html | Convert-Html2Xml

PS>$x1.Save(‘c:\temp\test1.xml’)

PS>$x3 = Convert-Html2Xml (gc c:\temp\testhtmlsource.html)

PS>$x3.Save(‘c:\temp\test2.xml’)

Tuto funkci můžeme například použít, pokud daná webová služba nemá přístupné API, ale uživatel s ní pracuje pouze přes její webové UI. Příkladem může být http://www.slovnik.cz. Kompletní řešení ve stylu quick&dirty zahrnuje i použití XPath pomocí cmdletu Select-Xml. 
Jiné řešení jsem rychle stvořil pro kolegu, který vytvářel seznam filům s linky na CSFD. nehledejte krásu, ale automatizaci 

A ještě jeden rychlý příklad: narazili jste na blog, který má velmi mnoho příspěvků a do stránky se vypisují celé příspěvky. Může vypadat například takto. Rádi byste věděli názvy jednotlivých článků, protože vás zajímá třeba o čem ten člověk píše? Samozřejmě můžete scrollovat, ale protože je stránka velmi dlouhá, hrozí nebezpečí, že něco zajímavého přeskočíte. Jaké je řešení?

$xml = Convert-Html2Xml (download-page ‘http://www.nivot.org/CategoryView,

category,PowerShell.aspx’ )

Select-Xml -Xml $xml -XPath ‘//div[@class=”itemTitle”]/a/text()’ | % 

{ $_.Node.Value }

Clipboard

Na první pohled si možná řeknete: “K čemu mi bude clipboard?”. Velmi často jej používám jako transportní mechanismus z nějaké aplikace do PowerShellu. Už jste v článku několikrát viděli použití funkce clip, ale tedy ještě pro zopakování ještě poslední příklad:

Mám problém s deadlocky na sql serveru. Spustím si jej tedy z konzole s přepínači kvůli detekci deadlocků. Poté, co se mi podaří nasimulovat deadlock, označím si obsah konzole sqlserveru a jdu do PowerShellu. Chci například zjistit jednotlivá SPID. Jak na to? 
(clip) | FindR -r ‘SPID: \d+’ 
Toto mi vypíše ID všech zúčastněných procesů (pro vynechání duplicit bychom použili select -unique).

Vím, že v SQL analyzeru je možné SPID také vidět, berte to jen jako příklad.

Podobných případů jistě naleznete dost. Funkce na práci s clipboardem máme tedy tyto:

Add-Type –a system.windows.forms

function Set-ClipBoard {

param(

[Parameter(Mandatory=$true,ValueFromPipeline=$true,Position=0)][object]$s

)

begin { $sb = new-object Text.StringBuilder }

process {

$s | % {

if ($sb.Length -gt 0) { $null = $sb.AppendLine(); }

$null = $sb.Append($_)

}

}

end { [windows.forms.clipboard]::SetText($sb.Tostring()) }

}

function Get-ClipBoard {

[windows.forms.clipboard]::GetText()

}

# funkce clip zastupuje Get-Clipboard i Set-Clipboard podle kontextu:

# gc c:\test.txt | clip

# clip | sc c:\test.txt

function clip {

param([Parameter(Mandatory=$false,ValueFromPipeline=$true)][object]$s)

begin { $sb = new-object Text.StringBuilder }

process {

$s | % {

if ($sb.Length -gt 0) { $null = $sb.AppendLine(); }

$null = $sb.Append($_)

}

}

end {

if ($sb.Length -gt 0) { $sb.Tostring() | Set-ClipBoard}

else                  { Get-ClipBoard  }

}

}

K tomu, aby přístup ke schránce fungoval, je nutné, aby PowerShell běžel s přepínáčem -sta, nebo abyste tento kód pouštěli v ISE prostředí. Pokud byste přesto chtěli mít přístup ke schránce i v MTA režimu, podívejte se na řešení.

Je to všechno?

Co by si zasloužilo alespoň zmínit, je cmdlet New-WebServiceProxy, dále práce s sql serverem (pomocí .NET prostředků), vytváření jednodušších GUI aplikací (ať už WinForms, nebo WPF). Tato témata se už do přehledu nevešla vzhledem k jejich rozsahu. Na internetu ovšem je k nalezení plno zdrojů, které zájemcům pomohou.

Za sebou mám základní věci, které vás jako vývojáře mohou uchvátit, nebo nechat chladným. Stále platí, že nejdůležitější je první bod – rychlé a efektivní řešení běžných úkolů a v tom se PowerShellu těžko něco vyrovná.

Seriál: Windows PowerShell – PS a Active Directory (část 7.)

Dnes podíváme na oblast, která možná zajímá většinu z vás – administraci Active Directory pomocí PowerShelu.

1.1 Možnosti

Nejprve se podívejme, jaké možnosti máme. Jako první můžeme spustit následující příkaz

PS C:\> admgmt.msc

OK, beru zpět, tuto metodu asi nemůžeme považovat za úplně PowerShell-like. Použitím některé z následujících technik už jsme na tom ale v konzoli PowerShellu lépe.

• ADSI

• .NET pomocí SDSP

• Quest cmdlets

• Windows 2008 R2 cmdlety nebo pomocí Active Directory Management Gateway Service pro nižší verze Windows serveru.

Já budu většinu příkladů ukazovat na cmdletech od firmy Quest. Mám k tomu dva hlavní důvody.

1.     Přístup přes ADSI mi přijde moc VBS-like. Nutno říci, že to není špatná cesta – pro některé z vás možná ta jediná použitelná (pokud mate například zakázáno instalovat nástroje třetích stran), nicméně na ADSI bylo v minulosti opravdu tolik příkladů, že by to bylo nošením dříví do lesa (krátkému srovnání se ale stejně budu věnovat). Pokud vás přístup přes ADSI bude zajímat, podívejte se na konec článku, kde uvádím odkaz na jednu moc zajímavou knihu.

2.     Nativní cmdlety (pro Windows 2008 R2) nejsou ještě tolik rozšířené. Přecijen R2 server tu s námi není tak dlouho a i když rozhodně předpokládám v budoucnu opravdu široké použití, zatím to prostě není ono.

1.2 Základní práce s AD

Typickým použitím PowerShellu při přístupu do AD je dotazovaní na uživatele, skupiny, členství ve skupinách, atd. Oproti AD konzoli máme výhodu v tom, že v konzoli množství dotazů ani nejsme schopni (při rozumném čase a úsilí) splnit. Zkuste například spočítat (a následně zobrazit v koláčovém grafu) množství lidí v konkrétních odděleních (organizačních jednotkách). Bez použití PowerShellu (nebo nástrojů třetích stran) máte práci asi tak na hodinu, s PowerShellem vyřešíte tento úkol za pět minut a zbytek oné hodiny se můžete koukat na slidy z poslední TechNet konference.

Poznámka: Cmdlety od firmy Quest jsou dostupné volně ke stažení. Nainstalujte je klasickým způsobem a poté je přidáte do aktuální konzole PoweShellu pomocí příkazu

PS C:\> Add-PSSnapIn Quest.*

Pokud je máte správně nainstalované, měl by vám následující příkaz vrátit všechny cmdlety pro práci s AD.

PS C:\> Get-Command –Module Quest.*

Pojďme si rovnou ukázat příklad z praxe:

PS C:\> Get-QADUser | Group-Object ParentContainer | Sort-Object Count -Descending | Select-Object Count, Name -First 5 | Out-Chart -xField ‘Name’ -yField ‘Count’

Tímto příkazem zjistíme pět oddělení s největším počtem zaměstnanců a zobrazíme je v grafu. Out-Chart není standardním příkazem PowerShellu a můžete si jej stáhnout ze stránek Chada Millera. Jako první provedeme pomocí Get-QADUser dotaz na všechny uživatele, pak je sdružíme podle organizační jednotky, seřadíme podle počtu a následně zobrazíme. Většinu cmdletů znáte z předchozích dílů a nyní vše skládáme dohromady pomocí rour v jeden funkční celek.

Dalším typickým dotazem do AD je zjišťování uživatelů se zamčenými nebo disablovanými účty.

PS C:\> Get-QADUser –SearchRoot domain.cz/UserOU –Locked

PS C:\> Get-QADUser -Disabled

Naprosto jednoduchý přístup, který přebírá vše dobré, co jste se již v PowerShellu naučili. Pokud chcete zamčené uživatele odemknout, stačí přidat rouru a další cmdlet a mate zase všechny uživatele zpět odemčené.

PS C:\> Get-QADUser –Locked | Unlock-QADUser

Jistě jste si všimli, že použité cmdlety mají strukturu <Verb>-QAD<Noun>. Firma Quest správně tušila, že i Microsoft přijde se svými cmdlety a přidáním prefixu QAD se vyhnula případným budoucím konfliktům. Na Windows 2008 R2 opravdu existuje cmdlet Get-ADUser.

Další zadání může být například následující. “Dokážeme zjistit, kolik jsme v loňském roce vytvářeli nových účtů?” Toto se vám může hodit v případě plánování zdrojů a alespoň přibližně můžete odhadnout vaše následné náklady. Řešením je tento krátký one-liner. Termínem one-liner se rozumí příkaz PowerShellu, který napíšete na jednu řádku. Už jsem ale viděl i one-linery na několik (desítek) řádek, pouze vhodně spojené rourou.

PS C:\> Get-QADUser -CreatedAfter “1/1/2009 00:00” -SearchRoot ‘domena/czOU’

Nutno podotknout, že účty po odchodu lidí nemažu, ale nechávám je určitou dobu ve speciální organizační jednotce, což se mi pro tento případ hodilo. Pro rozdělení na jednotlivá oddělení bych postupoval stejně jako v prvním příkladě.

1.3 Vytvoření nového uživatele

Pojďme si porovnat vytvoření nového uživatele pomocí ADSI a Quest cmdletů. Pokud jste někdy vytvářeli účty ve VBS, asi jste právě ADSI použili. Proto pro vás nebude následující příklad žádným překvapením:

PS C:\> $OU = [ADSI]LDAP://ou=czOU,dc=domain,dc=cz 
PS C:\> $User = $OU.Create(“user”, “cn=DavidM”) 
PS C:\> $User.Put(“sAMAccountName”, “davidm”) 
PS C:\> $User.SetInfo()

Pomocí Quest cmdletů vytvoříme uživatele následujícím způsobem:

PS C:\> New-QADUser -samAccountName ‘davidm’ -name ‘DavidM’ -ParentContainer ‘OU=czOU,DC=domain,DC=cz’

Ve Windows 2008 R2 můžete použít následující příkaz:

PS C:\> New-ADUser -SamAccountName “davidm” -DisplayName “DavidM” -Path ‘OU=czOU,DC=domain,DC=cz’

Při vytváření jednoho uživatele asi výhody konzole nepocítíte, ale představte si nástupy nových lidí každý rok a čas strávený s přípravou PowerShellí verze se vám vyplatí. Nebudu zde ukazovat použití při načítání nových uživatelů z CSV souboru. Takových příkladů existují na webu desítky. Odkážu vás ale na TechNet Magazine, kde se právě tomuto úkolu věnoval v několika pokračováních Don Jones.

1.4 Práce se skupinami

Pokud vytvoříte nového uživatele, musíte (měli byste) ho také přiřadit do skupiny. Opět se jedná o jednoduchý příkaz.

PS C:\> Add-QADGroupMember –identity cz\ProxyServerAccess –member davidm

Pokud potřebujete později zjistit všechny uživatele konkrétní skupiny, pomůže vám tento cmdlet:

PS C:\> Get-QADGroupMember cz\ProxyServerAccess

Práci se skupinami a vytváření uživatele můžete také spojit do jednoho příkazu

New-QADUser | Add-QADGroupMember

Úplně stejně můžete pracovat i s počítači. Asi dokážete odhadnout jméno cmdletu pro práci s nimi.

PS C:\> Get-QADComputer –SearchRoot ‘domain.cz/Domain Controllers’

Pokud budete některé cmdlety používat častěji a nehodí se vám jejich základní parametry, můžete si vytvořit vlastní funkci, do které tento cmdlet “zapouzdříte” (o funkcích si možná povíme něco později). Na mém počítači mohu například zjistit počet mnou upravených AD cmdletů takto:

PS C:\> (Get-Command *-DMAD* | Measure-Object).Count 
12

1.5 Další informace

Dnešní téma jsme vzali trochu “letem, světem”. Důvod je jednoduchý. Při práci s Active Directory je dobré si uvědomit jednu základní věc. Všechny potřebné cmdlety jsou vám k dispozici a je pouze na vás, jak je budete kombinovat dohromady. Vždy je dobré znát základy PowerShellu (cmdlety, které jsem ukazoval v předchozích dílech) a vše nové si přizpůsobit pro vlastní potřebu.

O PowerShellu a Active Directory bylo napsáno už mnoho článků. Nechtěl jsem zde opakovat některé často používané konstrukce. Pokud vás ale tento článek trochu vtáhl do tématu a rádi byste se dozvěděli více, uvádím zde několik zajímavých odkazů

• O tématu administrace AD pomocí PowerShellu vyšla celá kniha. Vydalo ji nakladatelství Sapien Press a jmenuje se Managing Active Directory with Windows PowerShell: TFM. Pokud ji chcete dostat zdarma, přihlaste se na těchto stránkách. Jedná se opravdu o velký zdroj informací o tomto tématu.

• V PowerShellu můžete například vytvořit testovací doménu se všemi potřebnými objekty. Stačí použít skript publikovaný naPoshCode.org. K prostudováni doporučuji i originální skript Dmitriho Sotnikova.

• Dmitry Sotnikov je vůbec cenným zdrojem práce s Active Directory. Další zajímavostí je například porovnání snapshotů stavu AD.

• Jestli vás více zajímají nativní cmdlety W2K8 R2, podívejte se na TechNet.

• Posledním odkazem je pro dnešek blog Active Directory PowerShell týmu.

Seriál: Windows Powershell – tipy a triky (část 8.)

Při práci v PowerShellu, stejně jako v jakémkoliv jiném programovacím či skriptovacím jazyku, narazíte čas od času na nějakou zajímavost, nebo obecný vzorec, který vám může usnadnit práci, zpřehlednit ji, nebo vám konečně pomůže pochopit nějaký obecný princip. V tomto článku vám předložím některé z těchto tipů a zajímavostí. Věřte ale, že je to jen malá část.

Navíc se snažím nerozebírat pokročilá témata, ale ukázat především tipy základní. Doufám, že alespoň některé z nich pro vás budou nové.

Konzole

Libovolná jména funkcí

PowerShell se používá dvěma různými způsoby: většinu kódu máme ve svých skriptech a tyto pouštíme podle potřeby. Anebo máme otevřenou konzoli a píšeme ps kód a spouštíme bez ukládání.

V prvním případě je velmi důležitá přehlednost kódu, jeho srozumitelnost a pochopitelnost. Proto se doporučuje používat plná jména cmdletů, ne jen gci ale Get-ChildItem (nehledě na to, že na jiném systému může gci být aliasem pro něco úplně jiného).

Ve druhém případě ovšem používáme hojně aliasů (gci|?{!$_.PSIsContainer}|select -exp Length) a co nejkratších konstrukcí. Důležité je dosáhnout cíle, ale téměř nezáleží na tom jak. Díky tomu, že PowerShell je velmi benevolentní, umožní nám pojmenovat funkce a aliasy velmi zajímavými jmény. Podívejte se na příklady.

I když PowerShell nechává na nás, jak se budou naše funkce jmenovat, dělejme tak s rozmyslem.

Zápis bytů

Nejlépe a okamžitě vše bude vidět na příkladu

Na konec číselné hodnoty můžete přidat jednotku (v bytech). PowerShell toto automaticky vyhodnotí za vás. V důsledku pak zjednodušíte kód např. takto: 
gci | ? { !$_.PSIsContainer -and $_.Length -gt 15mb }

Operátory a proměnné

Řetězení operátorů

Tato technika není příliš často používána, ale v mnoha případech dokáže nahradit použití cmdletů a pipeline. Pro demonstraci předpokládejme, že náš adresář obsahuje tyto soubory:

My z nich chceme vyfiltrovat jen ty, které začínají ch01. Z nich pak chceme získat pouze střední část zkonvertovatelnou na [datetime]. Tradičně bychom toto mohli provést přibližně takto:

Ale stejně tak můžeme použít i následující způsob. Všimněte si, že část select -exp Name v tomto případě není nutná, protože dojde ke konverzi [FileInfo] na string, při níž se bere jméno souboru.

Zde jsme použili dvou vlastností: 
Zaprvé – operátory se dají řetězit. Tedy i operátor replace by někdo kvůli čitelnosti mohli rozdělit na dva. Výsledek by pak vypadal takto:…-replace ‘ch01-‘,” -replace ‘\.txt’,”. Výsledek předchozího operátoru se uplatní při vyhodnocování následujícího operátoru. Toto jsem neviděl pořádně zdokumentované, tedy se odvolávám pouze na své dosavadní zkušenosti. 
Zadruhé – některé operátory pracují nejen nad skalárními hodnotami, ale také nad poli. Proto jsme mohli operátorům like a replacejako levý operand předat pole a vrátila se nám korektní hodnota. V případě, že bychom ale uvedený příklad chtěli dovést až do konce a hodnoty 2010-03-02 a podobné chtěli převést na datetime, pak toto je špatně: … -replace ‘ch01-|\.txt’,” -as [datetime]. V tomto případě se operátor snaží převést vstupní objekt (pole) na čas a toto pochopitelně nedopadne dobře. Stačí ale drobná změna a máme funkční kód.

Srovnejte:

Automatické proměnné $$, $^

$^ a $$ jsou automatické proměnné, které mají smysl hlavně při interaktivní práci v shellu. Ne vždy je použijete, ale hodí se je znát. O co jde, je nejlépe vidět na příkladu:

Proměnné obsahují první a poslední token na předchozím řádku. Přesněji: Contains the first token in the last line received by the session aContains the last token in the last line received by the session. 
Mohou vám tak ušetři hlavně psaní dlouhých cest do příkazů jako je Get-ChildItem, Get-Item atd. Otázka na StackOverflow dokládá, že se najdou tací, kteří tuto proměnnou skutečně používají.

Objekty

Objekty a typy

Pro mě nejužitečnější tip k práci s objekty a typy je přetypování. Nemám na mysli operátory, ale jednodušší způsob, jak využít jednoparametrický konstruktor. Příklady napoví.

Je tedy možné, pokud máme k dispozici jednoparametrický konstruktor, vyhnout se cmdletu New-Object a pouze použít přetypování.

Při vytváření instancí nějakého .NET typu je potřeba vždy uvádět plnou cestu. Například New-Object System.Text.StringBuilder. Co nám může pomoct?

Předně není nutné psát System. Kratší zápis vypadá takto:

Pokud máme vytvářet více instancí z jednoho namespace a nechceme pořád daný namespace opisovat, můžeme si jej uložit do proměnné:

Skládání stringů možná nikoho nepřekvapilo a možná to každému přišlo naprosto přirozené. Méně přirozeně může vypadat poslední tip k typům. 
Odkaz na třídu si můžeme uložit do proměnné a později použít hlavně při volání statických metod.

Přidávání properties k PSObject

Za časů PowerShell V1 se k instancím obecného objektu přídávaly property pomocí cmdletu Add-Member.

Někteří si život usnadňovali trikem pomocí Select-Object.

V PowerShellu V2 ale máme k dispozici nový parametr -property, který zápis velmi usnadní a zpřehlední. 
Už nikdy víc Add-Member a Select-Object jen kvůli přidání property!

Práce s hashtable

Pro nejjednodušší případy, kdy i vyrábění PSObjectu je pro nás zdlouhavé, můžeme použít hashtable. Přistupovat do ní totiž můžeme nejen pomocí hranatých závorek, ale i pomocí tečkové notace.

Někdy může být zajímavé i použití více hodnot do indexu:

Tento přístup má ale i své nevýhody: Pří přístupu přes tečkovou notaci nefunguje doplňování pomocí [TAB]. Navíc se tyto “objekty” nedají třídit podle dané “property”.

Cmdlety

Splatting

V PowerShellu V2 máme k dispozici splatting operátor @. Používá se při práci s parametry funkcí a cmdletů. Za běhu si můžeme určit, které parametry budeme chtít předat.

Všimněte si, že výstup z volání Write-Parameters je stejný v obou případech. Za jméno funkce/cmdletu můžeme předat pole, nebo hashtable, které určují vstupní parametry. 
Pokud předáme pole, účinek je podobný, jako bychom zapisovali pouze argumenty a spoléhali se na navázání na parametry pomocí pozice. 
Pokud předáme hashtable, argumenty jsou navázány stejně, jakobychom před každým z nich specifikovali jméno parametru.

Pozn.: vyhodnocování parametrů je relativně složitý proces. Více je popsáno v knize Windows PowerShell in Action. Rád bych jen upozornil, že v našem případě se nejdříve navážou argumenty určené explicitně, tj. před nimi je jméno parametru (např. -p1 P1). A až teprve poté se navazují zbylé argumenty pomocí pozice na dosud nenavázané parametry. 
V našem případě se tedy nejdříve naváže parametr p1 a p3. Teprve potom se začíná navazovat argument 2000. Parametr p1 už je navázaný, tedy je přeskočen. První volný je parametr p2, proto se hodnota naváže na něj. To stejné platí pro hodnotu 2. polozka v poli.

Splatting použijeme tehdy, pokud chceme využít už existujících cmdletů, jako je např. Get-ChildItem.

Alias = Get-Alias

Narazili jste někdy na použití např. alias gm a divili se, co je to vlastně ten alias zač? V seznamu funkcí se nenachází, stejně tak v seznamu aliasů a cmdletů. 
Podobně funguje date, job, childitem, item, verb, service, atd.

Pokud PowerShell zjistí, že neexistuje daný příkaz (např. můžeme mít definovanou funkci service), zjistí, zda existuje alias Get-…. Pokud alias existuje, zavolá jej. Pokud neexistuje, zkouší podobně existenci funkce a cmdletu a případně existující příkaz zavolá.

Vyhodnocení proměnné/výrazu v řetězci.

To, že se proměnné v řetězci vyhodnocují, ví asi každý, kdo s PowerShellem pracuje.

Pokud jde o proměnnou, která obsahuje pole hodnot, pak tyto hodnoty jsou spojeny pomocí speciální proměnné $ofs. Pokud bychom chtěli hodnoty oddělit pomocí svislítek, můžeme použít toto:

Mnohem pěknější je ovšem v tomto případě použít operátor -join než nějakou magickou proměnnou.

Pokud chceme přistupovat k property objektu uložené v proměnné, musíme už použít závorek:

Při vyhodnocování výrazu nejsme omezeni, tj. můžeme použít např. indexaci, můžeme vytvořit objekt, atd. Tato praktika se ovšem nedá obecně doporučit. Výraz lze téměř jistě vždy vyhodnotit dříve než až při použití v řetězci:

Pokud se ovšem seznam vnořených property dozvíme až za běhu, můžeme použít chytré metody ExpandString:

Parametr -OutputVariable

-OutputVariable je parametr společný všem cmdletům. Používá se v situacích, kdy cmdlet vrací nějaké objekty (tj. u Write-Host nemá smysl) a chceme zachytit výstup z daného cmdletu do proměnné. Může se nám např. hodit při debugování nebo na zjednodušení skriptů. 
V příkladech budu používat alias OV.

Tento parametr funguje podobně jako cmdlet Tee-Object, který má mimojiné také možnost uložit obsah do proměnné, ale jednak je použití parametru jednodušší, druhak je možné do proměnné přidávat předřazením znaménka +.

Ostatní Krátce

• Start-Transcript spustí “logování” toho, co se děje ve vaší konzoli. Hodí se především tehdy, když experimentujete s neznámým API – dodatečně se dají příkazy a výstupy prohlédnout a jednoduše najít, která cesta vedla k cíli. Na ukončení logování pak použijete cmdlet Stop-Transcript.

• ii adresář otevře adresář ve Windows Exploreru. ii soubor spustí default akci nad souborem.

• gci env: vylistuje systémové proměnné.

• Jestli vám někdy chyběl příkaz Stop-Pipeline, podívejte se na článek Cancelling a Pipeline.

• Pokud potřebujete z kolekce i odebírat, můžet použít ArrayList, nebo za určitých okolností využít i přiřazování do více proměnných. Příklad napoví: $pole = 1..10; while($pole) { $p,$pole = $pole; write-host $p }.

• Některé cmdlety mají dynamické parametry. Pokud se chcete na tyto parametry podívat podrobněji, doporučuji About Dynamic Parameters.

• Zkuste v konzoli napsat na nový řádek # a mačkat TAB. PowerShell vám bude vypisovat příkazy z historie, počínaje posledním. Je to lepší varianta pohybu pomocí šipek. V tomto případě se totiž nepohybuje po řádcích, ale po celých příkazech, které se roztáhnou přes více řádků. Když pak zkusíte napsat #<řetězec obsažený v nějakém předchozím příkazu>[TAB], bude nápověda cyklit jen po příkazech, které obsahují daný řetězec.

• A ještě jeden tip na doplňování pomocí TAB. V některých situacích si nepamatujete přesně jméno souboru, ale víte nějaký řetězec, který jeho jméno obsahuje, případně příponu. Pak stačí výraz zapsat pomocí wildcards c:\temp\log??iis* a zmáčknout [TAB]. Konzole bude nabízet jen soubory odpovídající wildcards.

• Windows API
  Možná je to všem programátorům zřejmé, možná ne, ale – v PowerShellu můžete pomocí Add-Type používat i Windows API. Joel Bennet má na PoshCode.org krásnou ukázku. Jeho modul umožní skrýt a zobrazit okna, nebo nastavit průhlednost oka. Použití je velmi jednoduché.

Pokud máte své vlastní tipy, které vám přijdou zajímavé, neváhejte a využijte komentářů. Ostatní čtenáři je jistě ocení!

Seriál: Windows Powershell – Nadstavby PowerShellu (část 9.)

Dnes se podíváme mimo standardní cmdlety dodávané přímo s PowerShellem a řekneme si něco o zdarma dostupných rozšířeních. Zároveň si ukážeme zdroje, které je dobré sledovat.

PowerGUI

PowerGUI je možná nejznámější, zdarma šířený, nástroj pro PowerShell. Obsahuje administrátorskou konzoli a editor skriptů.

Administrátorská konzole je podobná MMC konzoli (v3) a skládá se ze tří hlavních částí – stromové struktury, hlavního panelu a panelu akcí. Konzoli je možno rozšířit pomocí takzvaných management packů (analogie se snap-iny v MMC) a v současné době těchto management packů existuje několik desítek. Dostupné jsou na adrese [[www]]. Celý management pack je vlasně PowerShell skript, zabalený ve specifickém XML souboru (PowerGUI pro vás tento XML soubor generuje automaticky).

Druhou částí PowerGUI je editor skriptů. Dle mého názoru se jedná o velice zdařilý nástroj a pokud píšete skripty, měli byste mu určitě věnovat pozornost (a porovnat, zda vám nebude vyhovovat lépe, než standardně dodávané PowerShell ISE). Editor obsahuje všechny základní vlastnosti, které si můžeme jako administrátoři přát (vývojářům možná budou některé části chybět). Funguje zde Intelli-Sense (doplňování např. Vlastností a metod objektů, doplňování jmen proměnných, …), obsahuje možnost vkládání Snippetů (připravené složitější konstrukce), pěkně funguje debugování, zvýraznění syntaxe nebo například šikovný export skriptu do HTML, které pak můžete umístit na své stránky.

Před několika málo měsící uvedla firma Quest na trh také PowerGUI Pro. To obsahuje navíc možnost napojení na některý ze softwarů pro verzování a také možnost běhu PowerShellu přes webové rozhraní.

PSCX

PowerShell Community Extensions – jeden z prvních projektů, který před několika lety rozšířil možnosti PowerShellu v1 o velice zajímavé skripty. V současné době obsahuje 149 skriptů, například pro práci s archivy, HTML/XML nebo některé více „programátorské“, např. Invoke-GC. V současné době jsou dostupné dvě verze: produkční 1.2 dostupná jako PSSnapin, kompatibilní i s PS v1 a verze 2.0 Beta 2, která je dostupná pouze pro verzi 2 a instaluje se z modulu.

SQLPSX

SQL Server PowerShell Extensions – projekt, za kterým stojí hlavně Chad Miller. Obsahuje množství skriptů pro správu SQL serveru a pokud vám nestačí dva cmdlety dodávané se SQL serverem, zde si určitě vyberete. V poslední verzi byl do SQLPSX přidán modul pro práci v ISE (sqlise) a chystá se i database object browser (pak už opravdu nebudu potřebovat SSMS J U slqise bych se rád na chvilku zastavil po importování tohoto modulu se v menu objeví dvě nové položky: ISE Pack (o něm až za chvilku) a SQL Ise.

Pokud potřebujete udělat dotaz do vaší databáze, mohli byste postupovat třeba takto:

• V ISE naimportujte modul: ipmo sqlise. Uvidíte, že se vám změní prompt.

• Připojte se na danou databázi. 
  

V editoru zadejte jednoduché query (všimněte si, že jej schválně zadávám neformátovaný) 

• Pomocí klávesové zkratky CTRL+4 nechte sqlise váš kód naformátovat. 
  
  Stiskněte CTRL+ALT+F5 a tím dotaz spustíte. Po chvíli se vám objeví výstup v GridView. Title GridView je stejný jako jsou souboru v ISE – v mém případě tedy Untitled.ps1. 
  

Vzhledem k tomu, že celý isepack je psaný v PowerShellu není problém si jej upravit pro své potřeby. Některé základní možnosti konfigurace jsou dostupné přes menu Add-ons/SQLIse/Options

PowerShell Pack – WPK

S Windows 7 byl uvolněn také Resource Kit, který obsahuje jednu zajímavou část – Windows PowerShell Pack. Tento balík se skládá z několika modulů z nichž nejzajímavější je bezesporu WPK (Windows Presentation Foundation (WPF) PowerShell Pack) – sada skriptů pro tvorbu grafického rozhraní. Obsahuje 716 různých skriptů a jeho možnosti jsou prostě ohromné. S trochou trpělivosti můžete vytvořit jakékoli GUI. Například lehká obměna pro 10. úkol letošních Scripting Games by mohla vypadat takto:

New-Label “$((gwmi win32_computersystem).UserName)” -FontSize 30 -Show

Dalším nástrojem pro tvorbu grafických rozhraní jsou např. také PowerBoots od Joela Bennetta. I když jsou oba projekty velmi pěkné, pro někoho může být překážkou, že vytváření grafických komponent není úplně intuitivní. V tomto případě se může hodně hodit následující nástroj.

PrimalForms Community Edition

Pokud vám psaní GUI z příkazové řádky přijde nepohodlné (čemuž bych se opravdu nedivil), můžete použít PrimalForms Community Edition – další zdarma dostupný nástroj, tentokrát od firmy Sapien (nejznámější je zřejmě jejich nástroj PrimalScript, který se používá ve všech skriptovacích MOC kurzech).

Pomocí přetažení prvků z levého seznamu do formuláře si můžete navrhnout design a PrimalForms potom automaticky vygenerují kód. Do tohoto kódu poté pouze doplníte obsluhu jednotlivých prvků. Pokud jste někdy uvažovali a vytváření formulářů, tento nástroj se vám do začátků bude určitě hodit.

ISE pack

Zajímavý modul rozšiřující PowerShell ISE (součást PowerShell Packu). Do menu přidává několik užitečných rozšíření z nichž některé jsou vidět na následujícím obrázku.

Některé zajímavé zdroje

Seriál: Windows Powershell – Pasti, chytáky a nechtěná překvapení (část 10.)

Uživatelé, kteří začínají pracovat s PowerShellem se většinou rychle naučí základní příkazy a postupy. Po čase začnou vytvářet složitější skripty, ve kterých už mohou narazit na záludnosti a chytáky. Pojďme si odhalit některé z nich, abychom se jim už příště vyhnuli a nemuseli dumat nad tím, jestli je to bug, nebo ne.

Automatické odrolování (unrolling/flattening) kolekce

Ve složitějších skriptech budete volat funkce/cmdlety, jejich výsledek uchovávat v proměnné a následně s proměnnou budete pracovat. Potíž může nastat, pokud předpokládáte, že v proměnné máte vždy uloženou kolekci. 
Přestavme si následující kód:

PS> function GetCollection {

# vrátí jednoprvkové pole

@(new-object PsObject -property @{Date=get-date })

}

PS> $a = GetCollection

Jak byste očekávali, že se dostanete na property Date?

“Správně” by to mělo být takto: $a[0].Date 
Ale PowerShell nám jednoprvkovou kolekci vybalil (unrolled) a do proměnné $a přiřadil samotný objekt. Na datum se tedy dostaneme takto:

PS> $a.Date

Stejný problém se netýká jen vámi vytvořených funkcí, ale i vestavěných cmdletů:

PS> $a = Get-ChildItem c:\ *windows* # najde adresář s nainstalovanými windows, zřejmě bude jen jeden

PS> $a.CreationTime                  # vypíše, kdy byl vytvořen

Na této vlastnosti PowerShellu je nepříjemné to, že po volání funkce/cmdletu můžete mít v proměnné uloženou kolekci, nebo vybalený objekt (tj. ne jednoprvkovou kolekci). Ve skriptu pak musíte testovat jestli je proměnná typu pole, nebo ne.

Naštěstí zde existuje jedna velmi jednoduchá technika – zabalení volání funkce/cmdletu do pole:

PS> $a = @(GetCollection)

PS> $a[0].Date

8. června 2010 14:14:27

PS> $a = @(Get-ChildItem c:\ *windows*)

PS> $a[0].CreationTime

2. listopadu 2006 12:18:34

Na odrolování můžete narazit nejen u polí, ale i u dalších objektů, DataSety nevyjímaje.

Práce s $null místo kolekce

Tento případ tak trochu souvisí s předchozím. Předpokládejte tento kód:

PS> function GetRandomNumbers {

param([int]$min, [int]$max)

if ($min -lt $max) {

0..10 | % { Get-Random -min $min -max $max }

}

}

PS> $numbers = GetRandomNumbers 0 -10

PS> $numbers | % { write-host Number: $_ }

Number:

Co se stane, když zkusíte zadat minimum větší než maximum? Vypíše se pouze “Number: ” a žádné číslo. Důvodem je, že z funkceGetRandomNumbers se nám nic nevrátilo. Toto nic pak bylo při přiřazení do proměnné $numbers interpretováno jako $null. A protože je naprosto legální poslat do pipeline $null, místo čísla se nám vypsal $null, jehož reprezentace je prázdný string.

Náprava je opět velmi jednoduchá:

PS> $numbers = @(GetRandomNumbers 0 -10)

PS> $numbers | % { write-host Number: $_ }

Do proměnné $numbers se nám tentokrát uložilo prázdné pole, což je přesně to, co jsme chtěli.

Jen podotýkám, že z výrazu @($null) nám prázdné pole nevznikne!

Jak si více zamotat hlavu

Pokud máte pocit, že už víte, jak na to, možná teprve teď se vám rozsvítí. Opět začněme příkladem.

PS> function ReturnNothing { }

PS> ReturnNothing | % { "some value passed" }   # nevypíše nic

Tento kus kódu se chová tak, jak byste intuitivně čekali. Když funkce ReturnNothing nic nevrací, tak se do pipeliny nic nepošle.

PS> function ReturnNull { $null }

PS> ReturnNull | % { "some value passed" }   # vypíše řetězec 1x

A tady, když se zamyslíme, kód funguje opět podle očekávání. Funkce něco vrací (i když je to jen $null), tedy do pipeline něco posílá. Proto se řetězec vypíše.

PS> $nothing = ReturnNothing

PS> $rnull = ReturnNull

PS> $nothing | % { "some value passed" }  # vypíše řetězec 1x

PS> $rnull   | % { "some value passed" }  # vypíše řetězec 1x

Po přiřazení do proměnné, se výsledek nic z ReturnNothing transformuje na $null. Chová se tedy stejně jako u ReturnNull.

A nyní asi možná tušíte, že když obě volání funkcí uzavřete do operátoru @(..), bude se kód chovat opět intuitivně.

PS> $nothing = @(ReturnNothing)

PS> $rnull = @(ReturnNull)

PS> $nothing | % { "some value passed" }  # nevypíše nic

PS> $rnull   | % { "some value passed" }  # vypíše řetězec 1x

Co to znamená? Pokud explicitně vrátíte $null, musíte s tím počítat, protože i tento $null bude v pipeline zpracován.

Pokud byste si o tomto rysu PowerShellu chtěli přečíst ještě něco víc, v článku Effective PowerShell Item 8: Output Cardinality – Scalars, Collections and Empty Sets – Oh My! jej najdete přehledně popsaný.

Automatické vracení hodnot z funkce

Na začátek opět jedna krátká ukázka:

PS> function GetArrayList {

$a = new-object Collections.ArrayList

$a.Add(10)

$a.Add('test')

$a

}

PS> GetArrayList

0

1

10

test

Víte, co se stalo? Možná byste očekávali, že se vypíše pouze 10 a “test”. Jenže i samotná funkce Add něco vrací – index nově přidané položky. A protože jsme výstup z Add nezachytili, dostal se mezi návratové hodnoty.

Korektně bychom tyto položky mohli vyřadit (minimálně) třemi způsoby:

$a.Add(10) | out-null

$null = $a.Add(10)

[void]$a.Add(10)

Update: čtvrtý způsob využívá přesměrování.

$a.Add(10) > $null

Záleží na vás, který z nich je vám sympatičtější.

PowerShellí funkce se volá jinak než .NETí

Tento problém překvapí spíše jen začátečníky. Ale pořád se s ním dá setkat. 
Spočívá ve způsobu, jak se do funkce (a samozřejmě i cmdletu) předávají parametry. V mnoha programovacích jazycích se uzavřou do závorek a oddělí čárkou. Jenže v PowerShellu se pomocí čárky vytváří pole.

PS> function Test {

param($a1, $a2)

write-host A1: $a1

write-host A2: $a2

}

PS> Test (1, 2)        # špatně

PS> Test 1, 2          # špatně; chová ste stejně jako předchozí volání

PS> Test 1 2           # spravná varianta

V prvním a druhém případě jsme vlastně předali hodnoty pouze prvnímu parametru; do proměnné reprezentované druhým parametrem byl přiřazen $null.

Předání $null do .NET metody

V případě, že používáme .NET a potřebujeme do metody, která bere string parametr předat $null, máme smůlu. Na toto téma byl otevřen bug a snad se ho podaří pořešit do příští verze.

Na onom reportu je k nalezení také workaround. Tj. je to možné, ale … nepěkné.

Priorita operátorů

Z času na čas vás může zaskočit, proč se váš výraz vyhodnocuje jinak, než jste zamýšleli. V tom případě je možná na vině priorita operátorů.

PS> $x = 2

PS> $y = 3

PS> $a,$b = $x,$y*5

Co byste jako programátoři očekávali v proměnných $a a $b? Po mé otázce už to zřejmě nebude 2 a 15. Operátor čárky má totiž větší prioritu než násobení.

Posholic kdysi experimentálně vytvořil tabulku s prioritou operátorů. Možná mezi nimi najdete i nějaké doposud neznámé kousky.

Operátor -f

S operátorem -f pracujte jen tehdy, když víte, že s ním pracujete správně  Podle všeho byla do jeho implementace zanesen bug.

Ve zkratce řečeno … operátor špatně vyhodnocuje, pokud mu podstrčíme jako pravý operand pole. Vyzkoušet si to můžete na tomto příkladě:

PS> $a = 1,2,3

PS> "{0} a {1}" -f $a

1 a 2

PS> $a.Length

3

PS> "{0} a {1}" -f $a

Error formatting a string: Index (od nuly) musí být větší nebo roven

nule a menší než velikost seznamu argumentů..

At line:1 char:13 …

Vtip je v tom, že $a není při prvním formátování obalena do PsObject instance a proto se vyhodnotí stejně, jakobychom zapsali "{0} a {1}" -f $a[0], $a[1], $a[2]. Možná vám to připomíná splatting.

Tím, že přistoupíme k property objektu (!), se tento objekt obalí do PsObject. Při vyhodnocení formátování pak je tento objekt konvertován na string a přiřazen do {0}. Do {1} už není co přiřadit a tedy skončíme s chybou.

Více informací najdete na StackOverflow.

Specifikujte typy u parametrů funkcí

PowerShell je dost chytrý a provádí plno konverzí na pozadí, o kterých ani nevíme, ale ne vždy je schopen si poradit. Příkladem může být toto:

PS> Function Test {

param($n, $k)

if($n -lt 0 -Or $k -lt 0) {

throw "Negative argument in Test"

}

"Processing"

}

PS> Test 1 –2

Processing

Přirozeně byste očekávali, že funkce vyhodí vyjímku. Bohužel se tak nestane. Parametry funkce nemají specifikován typ a tedy PowerShell z nějakých důvodů konvertoval argumenty na string.

Upravte hlavičku:

PS> Function Test {

param([int]$n, [int]$k)

...

PS> Test 1 -2

Negative argument in Test

At line:4 char:14 …

A dostanete očekávaný výsledek.

Generické typy

Vývojáři rychle zjistí, že PowerShell má omezenou podporu generických typů. Můžeme sice vytvořit například List<string> (syntaxe ze C#), ale:

• Už nemůžeme volat generickou metodu v negenerické třídě.

• Někdy je potřeba specifikovat fullname typu, viz. Powershell Generic Collections na StackOverflow.

Díky tomu nemůžeme plnohodnotně prozkoumávat neznámé assembly a musíme si pomáhat berličkami jako Invoking Generic Methods on Non-Generic Classes in PowerShell.

Vyhodnocování proměnných v řetězcích

Čas od času se najde někdo, kdo se potýká s vyhodnocováním proměnných v řetězci:

PS> $date = get-date

PS> "Teď je $date.Hour hodin"   # špatně

PS> "Teď je $($date.Hour) hodin" # správně

Pozor na proměnnou $args

Proměnná $args se používá hlavně u jednoduchých funkcí. Musíme ale vědět, kdy ji použít.

PS> function Test {

Write-Host args: $args

1..3 | Foreach-Object { write-host args je $args }

}

PS> Test 1 2 3

args: 1 2 3

args je

args je

args je

Jaktože proměnná nebyla vyhodnocena v rámci cmdletu Foreach-Object? 
Důvod je velmi prostý. Proměnná $args je automatická a inicializuje se v rámci každého volání funkce, skriptu, nebo scriptblocku. V tomto případě byl proveden scriptblock. V rámci toho byla vytvořena automatická proměnná $args, navázaná defaultně na $null.

Způsobů, jak toto obejít je více. Nejjednodušší z nich je odložit si $args do speciální proměnné a tu pak používat, tj. $a = $args … write-host args je $a.

Předávání argumentů externím programům

Z PowerShellu můžete přímo spouštět ostatní programy, má to ovšem jedno Ale. Někdy je velmi těžké skloubit způsoby, jakým funguje PowerShellí parser a požadavky na syntaxi argumentů pro daný program. Mohou vám chybět uvozovky, může vám dělat problém středník, mezera.

Pokud potřebujete vědět, jak přesně jsou argumenty předány vašemu programu, použijte program EchoArgs z PSCX modulu. Jak na to?

PS> import-Module pscx

PS> echoargs "argument" second 3rd 'before;after' -like-switch outside"inside"'inside2'"'inside3'"

Arg 0 is <argument>

Arg 1 is <second>

Arg 2 is <3rd>

Arg 3 is <before;after>

Arg 4 is <-like-switch>

Arg 5 is <outsideinsideinside2'inside3'>

Přesměrování do souboru a kódování

Možná jste zvyklí přesměrovat výstup z nějakého programu do souboru pomocí >, případně >>. Pak byste měli vědět, že výstup bude uložen do souboru v UNICODE. Je to ekvivalent … | out-file soubor -encoding unicode.

Obsah tedy můžete přesměrovat ručně pomocí Out-File a při tom specifikovat kódování.

Seriál Windows Powershell: Funkce (část 11.)

Základní konstrukce při práci s funkcemi

Až do minulého dílu jsme se věnovali primárně práci v konzoli. S tou si vystačíme pro většinu administrátorských úkonů. Pokud ale budeme PowerShell využívat pro složitější zprávu, bude se nám časem hodit možnost psaní skriptů. Dnes si řekneme něco o funkcích. Budeme je považovat za základní stavební jednotku skriptu. Funkce můžete psát velmi krátké pro jednostranné použití nebo složitější např. pro zpracování objektů z roury. Takzvané advanced funkce nám například umožní jednoduché vložení nápovědy. Začněme tedy nějakou minimalistickou funkcí.

PS C:\ function Get-FreeDiskSpace { (gwmi win32_logicaldisk -filter ‘DeviceID=”C:”‘).freespace/1GB } 
PS C:\ Get-FreeDiskSpace 
196.306255340576

Nadefinovali jsme si funkci, která nám po zavolání vrátí volné místo na disku C. Za klíčovým slovem function uvedeme jméno funkce a poté ve složených závorkách tělo funkce. Zatím nic světoborného, pojďme do funkce přidat nějaké vstupní parametry. Stejně jako v předchzím případě můžete text celé funkce zapsat přímo do konzole nebo použít některý z editorů, např. PowerShell ISE. Editor nám přináší (mimojiné) výhodu zvýrazňování syntaxe a tím i snadnější hledání chyb.

function Get-FreeDiskSpace 
{ 
param 
( 
  $drive = ‘C:’ 
) 
  $filter = ‘DeviceID=”‘ + $drive + ‘”‘ 
  (Get-WmiObject Win32_LogicalDisk -filter $filter).FreeSpace/1GB 
}

Poznámka: Čtenáře už by neměla překvapit konstrukce “1GB”.

Přidali jsme klíčové slovo param a použili pro parametr jméno drive. Nyní můžeme volit, na jakém disku nás volné místo zajímá, přičemž standardní hodnota je disk C.

PS C:\> Get-FreeDiskSpace 
196.615299224854 
PS C:\> Get-FreeDiskSpace C: 
196.615299224854 
PS C:\> Get-FreeDiskSpace D: 
0 
PS C:\> Get-FreeDiskSpace -drive C: 
196.615299224854

V prvním případě voláme funkci bez parametrů a vráceno je množství volného místa na disku C, stejně jako ve druhém případě, kde jsme – trochu zbytečně – uvedli jméno disku. Třetí příklad na mém počítači vrátí nulu (disk D není v systému). Ve čtvrtém případě voláme funkci i se jménem parametru. Toto je vhodné při větším množství parametrů – zlepšujeme čitelnost kódu.

Poznámka: Někteří z vás možná znají z jiných jazyků proměnnou s názvem args. PowerShell jí také disponuje, můžeme ji využít, ale při tvorbě vlastních funkcí bych se ve většině případů klaněl k pojmenování parametrů tak, jako v předchozím případě. Nicméně pouze pro názornost:

PS C:\> function Get-Args { “Pocet parametru: $($args.Count)”; “Parametry: $args” } 
PS C:\> Get-Args aaa bbb ccc 
Pocet parametru: 3 
Parametry: aaa bbb ccc

Zajímavou možností je při definici parametrů funkce určit rovnou i jejich typ. Následující definice

PS C:\ function test { param ([int]$text) }

Nám při následujících typech volání buď projdou bez chyby nebo oznámí, že máme problém.

PS C:\> test 1 
PS C:\> test aaa 
test : Cannot process argument transformation on parameter ‘text’. Cannot convert value “aaa” to type “System.Int32”. 
Error: “Input string was not in a correct format.” 
At line:1 char:5 
+ test <<<< aaa 
+ CategoryInfo : InvalidData: (:) [test], ParameterBindin…mationException 
+ FullyQualifiedErrorId : ParameterArgumentTransformationError,test

Vidíme, že PowerShell hlásí chybu konverze řetězce „aaa“ na číslo (typ int32). Zajímavým typem proměnné je přepínač (switch), který nám umožňuje rozhodování typu ano-ne. Vraťme se k naší první funkci Get-FreeDiskSpace, nyní přidáme možnost zobrazit množství volného místa v bytech (tak, jak jej vrátí cmdlet Get-WmiObject) nebo přepočtený na GB, jako v naší původní funkci.

function Get-FreeDiskSpace 
{ 
param 
  ( 
  $drive = ‘C:’, 
  [switch]$gb 
  ) 
  $filter = ‘DeviceID=”‘ + $drive + ‘”‘ 
   if($gb) 
   { 
   (Get-WmiObject Win32_LogicalDisk -filter $filter).FreeSpace/1GB 
   } 
   else 
   { 
   (Get-WmiObject Win32_LogicalDisk -filter $filter).FreeSpace 
  } 
}

Parametr gb je typu [switch] a jeho uvedení při volání funkce ukáže volné místo v GB.

PS C:\> Get-FreeDiskSpace 
211123945472 
PS C:\> Get-FreeDiskSpace -gb 
196.624496459961

Poznámka: Všimněte si, že při zadávání jednotlivých parametrů funkce můžete používat pro doplňování jmen klávesu “Tab” stejně jako při práci s cmdlety.

Pokročilé funkce

Pokud znáte funkce z PowerShellu v1, nebyly pro vás předchozí řádky vůbec žádnou novinkou. V PowerShellu v2 byl ovšem uveden concept takzvaných advanced functions (osobně nemám moc rád překlady zažitých anglických názvů do češtiny a nadpis této kapitoly je výjimkou).

Advanced functions přidávají několik klíčových slov a umožňují lepší kontrolu parametrů. Další přidanou hodnotou je možnost tvorby velice pěkné nápovědy (stejné jako mají cmdlety). Ukažme si, jak by mohla definice vstupního parametru vypadat.

function Show-ParameterAttribute 
{ 
   param ( 
      [Parameter( 
      Mandatory=$true, 
      Position=0, 
      ParameterSetName=”set1″, 
      ValueFromPipeline=$false, 
      ValueFromPipelineByPropertyName=$false, 
      ValueFromRemainingArguments=$false, 
      HelpMessage=”Enter parameter #1.”)] 
      [Alias(“p1”)] 
      [int] 
      $param1 
   ) 
  Write-Output $param1 
}

Vidíme, že se nám možnosti pro definici parametrů pěkně rozrostly. Význam většiny atributů je zřejmě jasný z názvů, pojďme se nejdříve podívat, jak funguje naše funkce a poté si povíme o atributech podrobněji.

PS C:\> Show-ParameterAttribute 
cmdlet Show-ParameterAttribute at command pipeline position 1 
Supply values for the following parameters: 
(Type !? for Help.) 
param1: !? 
Enter parameter #1. 
param1: 0 
0 
PS C:\> Show-ParameterAttribute -param1 1 
1 
PS C:\> Show-ParameterAttribute -p1 2 
2 
PS C:\> Show-ParameterAttribute 3 
3 
PS C:\> Show-ParameterAttribute 4 5 
Show-ParameterAttribute : A positional parameter cannot be found that accepts argument ‘5’. 
At line:1 char:24 
+ Show-ParameterAttribute <<<< 4 5 
+ CategoryInfo : InvalidArgument: (:) [Show-ParameterAttribute], ParameterBindingException 
+ FullyQualifiedErrorId : PositionalParameterNotFound,Show-ParameterAttribute

Jelikož jsme parametr nastavili jako Mandatory, PowerShell nám při volání funkce bez parametrů oznámí, že musíme zadat hodnotu pro param1. Po vyvolání nápovědy pro parametr (označeno žlutě) se zobrazí text, který jsme zadali jako atribut HelpMessage. Při druhém volání jsme zadali parametr i se jménem a při třetím využili možnost námi definovaného aliasu. Ve čtvrtém případě zafungoval atributPosition. Poslední volání nám oznámí, že zadaná hodnota (5) nemůže být zpracována, protože nám „nezbyl“ parametr, kam bychom ji uložili. Pokud očekáváme, že na vstup se mohou dostat nějaké další parametry, které nechceme ztratit, můžeme změnit atributValueFromRemainingArguments na $true. Pokračujeme definicí nového parametru.

[Parameter(ValueFromRemainingArguments=$true)]$param2 
PS C:\> Show-ParameterAttribute 4 5 6 7 
param1: 4, param2: 5 6 7

Vidíme, že parametr param1 obsahuje první hodnotu a zbývající tři jsou obsaženy v param2 (v těle funkce jsme změnili výpis na: Write-Output “param1: $param1, param2: $param2”). Nejenom, že můžeme ovlivňovat chování parametrů, můžeme je rovnou na vstupu funkce testovat na určité hodnoty. Tím nám v tělě funkce odpadnou podmínky typu if-else a kód bude tím pádem čitelnější. Můžeme použít následující atributy (takzvané Parametr Validation Attributes).

• AllowNull – umožňuje, aby parametr obsahoval hodnotu null. Platí i pokud je parametr nastaven jako mandatory.

• AllowEmptyString – parametr může být prázdný řetězec.

• AllowEmptyCollection – stejné jako předchozí dva, ale pro prázdnou kolekci.

• ValidateCount – určuje minimální a maximální počet argumentů.

• ValidateLength – určuje délku parametru.

• ValidatePattern – specifikuje regulární výraz, kterým můžeme určit vzor parametru.

• ValidateRange – minimální a maximální hodnota parametru.

• ValidateScript – může obsahovat skript, který validuje parametr. Pokud skript vrátí hodnotu false, PowerShell zahlásí chybu validace.

• ValidateSet – parametr může obsahovat pouze uvedené hodnoty.

• ValidateNotNull – hodnota parametru neůže být null.

• ValidateNotNullOrEmpty – hodnota nemůže být null nebo prázdný řetězec.

Ukažme si krátký příklad.

function Test-Parameter 
{ 
   param ( 
   [Parameter(Mandatory=$True,Position=0)] 
   [string] 
   [ValidateSet(“David”)] 
   $jmeno, 
   [Parameter(Mandatory=$true,Position=1)] 
   [int] 
   [ValidateRange(33,33)] 
   $vek 
   ) 
   Write-Output “Autorem je $jmeno a je mu $vek let.” 
}

Tato funkce vypíše, kdo je autorem tohoto článku, ovšem pouze za podmínky, že zadáme správně jméno a věk.

PS C:\> Test-Parameter Petr 33

Test-Parameter : Cannot validate argument on parameter ‘jmeno’. The argument “Petr” does not belong to the set “David” specified by the ValidateSet attribute. Supply an argument that is in the set and then try the command again. 
At line:1 char:15 
+ Test-Parameter <<<< Petr 33 
+ CategoryInfo : InvalidData: (:) [Test-Parameter], ParameterBindingValidationException 
+ FullyQualifiedErrorId : ParameterArgumentValidationError,Test-Parameter

PS C:\> Test-Parameter David 32

Test-Parameter : Cannot validate argument on parameter ‘vek’. The 32 argument is less than the minimum allowed range of 33. Supply an argument that is greater than 33 and then try the command again. 
At line:1 char:15 
+ Test-Parameter <<<< David 32 
+ CategoryInfo : InvalidData: (:) [Test-Parameter], ParameterBindingValidationException 
+ FullyQualifiedErrorId : ParameterArgumentValidationError,Test-Parameter

PS C:\Scripts> Test-Parameter David 33

Autorem je David a je mu 33 let.

Vidíme, že jsme zkusili zadat špatně buď věk nebo jméno a v obou případech jsme obdrželi chybové hlášení. Až v posledním případě proběhlo vše podle předpokladů.

Tvorba nápovědy

Posledním dnešním tématem bude vytvoření nápovědy pro naši vlastní funkci. Asi jako většina lidí se mohu přiznat k tomu, že jsem líný psát dokumentaci k vlastním skriptům. I když netvrdím, že ve verzi 2 se za vás dokumentace napíše sama, alespoň nám PowerShell tým trošku ulehčil práci. V každém případě jde ale především o naši vlastní vůli zadat těch pár klíčových slov navíc. Určitě už jste použili v kódu znak # – cokoli od tohoto znaku do konce řádky je bráno jako komentář. Ve verzi 2 přibyla možnost použít znaky <# a #> a cokoli mezi těmito znaky je bráno jako komentář, tento komentář může zasahovat přes více řádek. Této vlastnosti lze využít právě pro vytvoření vlastní nápovědy – jedinou podmínkou je, že použijeme speciální klíčová slova.

Pojďme si vytvořit help pro první funkci z tohoto článku.

function Get-FreeDiskSpace 
{ 
<# 
.Synopsis

Funkce zjišťuje volné místo na disku.

.Description 
Pomocí WMI třídy Win32_LogicalDrive zjistí volné místo na zadaném disku.

.Parameter drive 
Určuje disk, pro který zjišťujeme volné místo.

.Example 
Get-FreeDiskSpace 
129.7597

.Example 
Get-FreeDiskSpace -drive D: 
10.86

.Link 
Get-WmiObject 
#>

param 
  ( 
    $drive = ‘C:’ 
  )

$filter = ‘DeviceID=”‘ + $drive + ‘”‘ 
(Get-WmiObject Win32_LogicalDisk -filter $filter).FreeSpace/1GB

}

Při volání nápovědy se zobrazí následující text.

PS C:\> Get-Help Get-FreeDiskSpace -Full

NAME 
Get-FreeDiskSpace

SYNOPSIS 
Funkce zjišťuje volné místo na disku.

SYNTAX 
Get-FreeDiskSpace [[-drive] <Object>] [<CommonParameters>]

DESCRIPTION 
Pomocí WMI třídy Win32_LogicalDrive zjistí volné místo na zadaném disku.

PARAMETERS 
-drive <Object>

Určuje disk, pro který zjišťujeme volné místo. 
Required?                                          false 
Position?                                           1 
Default value 
Accept pipeline input?                     false 
Accept wildcard characters?

<CommonParameters> 
This cmdlet supports the common parameters: Verbose, Debug, 
ErrorAction, ErrorVariable, WarningAction, WarningVariable, 
OutBuffer and OutVariable. For more information, type, 
“get-help about_commonparameters”.

INPUTS

OUTPUTS

————————– EXAMPLE 1 ————————–

C:\PS>Get-FreeDiskSpace 
129.7597

————————– EXAMPLE 2 ————————–

C:\PS>Get-FreeDiskSpace -drive D: 
10.86

RELATED LINKS 
Get-WmiObject

Vidíme, že bez zbytečně velké námahy máme vygenerovanou velice pěknou nápovědu. Tím bychom pro dnešek skončili. Pokud vás tvorba funkcí zaujala, zkuste se podívat na následující témata nápovědy:

• about_functions_advanced

• about_functions_advanced_methods

• about_functions_advanced_parameters

• about_Comment_Based_Help

Seriál Windows Powershell: Funkce 2 (část 12.)

V minulém díle jsme se plně věnovali funkcím. I když jsem chtěl dnes navázat tématem skripty a moduly, rozhodl jsem se téma funkcí ještě trochu rozšířit použitím atributu CmdletBinding. Vzhledem k tomu, že funkce považuji za základní stavební kameny pokročilejšího skriptování, nemyslím, že by to bylo na škodu. O skriptech a modulech si tedy povíme až v některém z příštích pokračování.

Opravdu pokročilé funkce

Použití [CmdletBinding()]

Možná už jste četli tématickou nápovědu about_Common_Parameters a slyšeli jste, že je možné tyto parametry využívat ve vašich funkcích. Malá zmínka je v další tématické nápovědě (about_Functions_CmdletBindingAttribute) a tato dale odkazuje na MSDN, kde se můžete dočíst více. Abyste se nemuseli prokousávat celou dokumentací, ukážeme si jednoduché použití atributu CmdletBinding.

Mějme základní “tupou” funkci.

PS C:\> function secti {param($a,$b) $a+$b} 
PS C:\> secti 5 6 
11

Zjistíme, jaké má funkce parametry:

PS C:\> (gcm secti).Parameters | select -expand Keys 
a 
b

Z minulého dílu víme, že můžeme do funkce přidat nápovědu, validaci parametrů, atd., ale pořád nevidíme žádný z “common parameters”. Přidejme tedy atribut CmdletBinding.

PS C:\> function secti {[CmdletBinding()] param($a,$b) $a+$b} 
PS C:\> secti 1 5 
6

PS C:\> (gcm secti).Parameters | select -expand Keys 
a 
b 
Verbose 
Debug 
ErrorAction 
WarningAction 
ErrorVariable 
WarningVariable 
OutVariable 
OutBuffer

Bez jakékoli větší práce nám tvůrci PowerShellu dodali další zajímavé parametry.

Pozor: Tímto jsme nevytvořili vlastní cmdlet. Stále se jedná o funkci. Cmdlety jsou odvozené od tříd Cmdlet nebo PsCmdlet. Možno ověřit např. i následujícím způsobem:

PS C:\> (Get-Command Get-Command).GetType().FullName 
System.Management.Automation.CmdletInfo

PS C:\> (Get-Command secti).CmdletBinding 
True

PS C:\> (Get-Command secti).GetType().FullName 
System.Management.Automation.FunctionInfo

Více k CmdletInfo a FunctionInfo lze dohledat opět na MSDN.

Vytvořme si novou funkci, která bude opět sčítat dvě čísla.

function Get-Soucet 
{ 
[CmdletBinding()] 
param ( 
[int]$a = 1, 
[int]$b = 1 
)

Write-Verbose “Vstupni cislo a: $a” 
Write-Verbose “Vstupni cislo b: $b”

Write-Verbose “Pred scitanim.” 
$soucet = $a + $b 
Write-Verbose “Secteno jako: $soucet”

Write-Host “Soucet cisel $a a $b je $soucet.”

Write-Verbose “Konec funkce.” 
}

Povšimněte si použití Write-Verbose. Jedná se o naše vlastní “kontrolní” výpisy, kterými můžeme zjišťovat stav funkce v průběhu jejího běhu.

PS C:\Scripts> Get-Soucet 
Soucet cisel 1 a 1 je 2. 
PS C:\Scripts> Get-Soucet 5 5 
Soucet cisel 5 a 5 je 10. 
PS C:\Scripts> Get-Soucet 5 5 -Verbose 
VERBOSE: Vstupni cislo a: 5 
VERBOSE: Vstupni cislo b: 5 
VERBOSE: Pred scitanim. 
VERBOSE: Secteno jako: 10 
Soucet cisel 5 a 5 je 10. 
VERBOSE: Konec funkce.

Vidíte, že při použití parametru Verbose jsme dostali navíc informace, které se nám mohou hodit v průběhu ladění. Pokud si tuto techniku zapamatujete, odpadne vám běžný problem se zadáváním Write-Host na různá místa a poté jeho odstraňování.

Chcete opravdu zmáčknout to červené tlačítko?

Pro někoho jsou možná dialogová okna s nápisy – “Are you sure you want to …” (doplňte dle libosti) – otravná, ale zřejmě pouze do doby, než jsou na konci okna slova “doména” a “smazat” nebezpečně blízko u sebe. Administrace v PowerShellu (nebo spíše obecně v příkazové řádce, skriptu, …) je skvělá, rychlá, méně náchylná na lidské chyby, ale má samozřejmě svá rizika. Například spojení cmdletů Get-ADUser aRemove-ADUser na jedná řádce vám může bez dobrého filtrování způsobit docela těžkou hlavu (poděkujme za Enable-ADOptionalFeature).

Možnost vložit so svých skriptů dotaz na provedení akce se hodí při jakékoli destruktivní operaci. PowerShell v2 nám toto umožňuje, pojďme se podívat jak na to. Nejdříve si ukážeme celou funkci a poté vysvětlíme jak funguje.

function Invoke-Phobia 
{ 
[CmdletBinding(SupportsShouldProcess=$true)] 
param ( 
[int]$cislo, 
[switch]$mocnina 
)

“Soucet: $($cislo+$cislo)” 
if ($mocnina) 
{ 
if ($PsCmdlet.ShouldProcess(“$cislo”, “Pata mocnina”)) 
{ 
“Mocnina $([Math]::Pow($cislo, 5))” 
} 
} 
}

Jak vidíte, přidali jsme parametr SupportsShouldProcess. Funkce nám okamžitě nabízí dva nové parametry – WhatIf a Confirm.

PS C:\> (gcm Invoke-Phobia).Parameters | select -expand Keys 
cislo 
mocnina 
Verbose 
Debug 
ErrorAction 
WarningAction 
ErrorVariable 
WarningVariable 
OutVariable 
OutBuffer 
WhatIf 
Confirm

Tyto parametry lze použít u velké části cmdletů, takže například

PS C:\> Remove-Item *.ps1 -WhatIf 
What if: Performing operation “Remove File” on Target “C:\Scripts\profile.ps1”. 
What if: Performing operation “Remove File” on Target “C:\Scripts\VeryVERYuseful-DO_NOT_DELETE.ps1”.

nám dá šanci zareagovat při nesprávném použití. A teď zpět k naší funkci – provádí dvě operace, jednu nedestruktivní (součet – provádí se při každém volání) a jednu destruktivní (pátou mocninu – provede se pouze, pokud uvedeme switch mocnina). Destruktivní proto, že náš klient má fobii na vysoká čísla a mocnina by ho mohla rozrušit. Pojďme si tedy naši funkci vyzkoušet.

PS C:\> Invoke-Phobia 5 
Soucet: 10

PS C:\> Invoke-Phobia 5 -WhatIf 
Soucet: 10

PS C:\> Invoke-Phobia 5 -mocnina 
Soucet: 10 
Mocnina 3125

PS C:\> Invoke-Phobia 5 -mocnina -WhatIf 
Soucet: 10 
What if: Performing operation “Pata mocnina” on Target “5”.

PS C:\> Invoke-Phobia 5 -mocnina -Confirm 
Soucet: 10

Confirm 
Are you sure you want to perform this action? 
Performing operation “Pata mocnina” on Target “5”. 
[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help (default is “Y”): 
Mocnina 3125

Při prvním volání dostaneme pouhý součet hodnoty. Stejně tak se nic převratného nestane, pokud použijeme parametr WhatIf bez volání mocniny. Zajímavá je pro nás až třetí varianta – volání mocniny a zaroveň uvedení WhatIf. PowerShell nám ukáže, co by se mohlo stát v případě, ze funkci spustíme bez WhatIf. Všimněte si, že parametry, které jsme uváděli u metody ShouldProcess se nám objevily ve výpisu. Použití Confirm je poté již jen rutinní záležitostí.

Použití WhatIf při každém volání

Představte si situaci, kdy pracujete se skutečně kritickým systémem a chcete mít jistotu, že v předchozích odstavcích zmiňované „bezpečnostní mechanismy“ jsou spouštěné při každém volání „destruktivního“ cmdletu nebo funkce.

C:\Script>ls | select name | fw -c 5 
file1.txt file10.txt file2.txt file3.txt file4.txt 
file5.txt file6.txt file7.txt file8.txt file9.txt

C:\Scripts>Remove-Item * -WhatIf 
What if: Performing operation “Remove File” on Target “C:\Scripts\file1.txt”. 
What if: Performing operation “Remove File” on Target “C:\Scripts\file10.txt”. 
What if: Performing operation “Remove File” on Target “C:\Scripts\file2.txt”. 
(…)

C:\Scripts>Remove-Item * 
What if: Performing operation “Remove File” on Target “C:\Scripts\file1.txt”. 
What if: Performing operation “Remove File” on Target “C:\Scripts\file10.txt”. 
What if: Performing operation “Remove File” on Target “C:\Scripts\file2.txt”. 
(…)

C:\Scripts>Remove-Item * -Force 
What if: Performing operation “Remove File” on Target “C:\Scripts\file1.txt”. 
What if: Performing operation “Remove File” on Target “C:\Scripts\file10.txt”. 
What if: Performing operation “Remove File” on Target “C:\Scripts\file2.txt”. 
(…)

C:\Scripts>ls | select name | fw -c 5 
file1.txt file10.txt file2.txt file3.txt file4.txt 
file5.txt file6.txt file7.txt file8.txt file9.txt

Jak vidíte ani parametrem Force se nám nepodařilo donutit cmdlet Remove-Item, aby smazal dané soubory. Což by se nám mohlo hodit, pokud bychom se pohybovali např. o adresář výš, než jsme nyní. V PowerShellu existuje proměnná, která se jmenuje WhatIfPreference a určuje chování parametru WhatIf.

C:\Scripts>ls Variable:\WhatIfPreference | fl * 
PSPath : Microsoft.PowerShell.Core\Variable::WhatIfPreference 
PSDrive : Variable 
PSProvider : Microsoft.PowerShell.Core\Variable 
PSIsContainer : False 
Name : WhatIfPreference 
Description : If true, WhatIf is considered to be enabled for all commands. 
Value : False 
Visibility : Public 
Module : 
ModuleName : 
Options : None 
Attributes : {}

Z parametru Description můžeme vyčíst, jak tato proměnná funguje. Standardně je nastavena na False a ve všech předchozích případech jsem ji ručně nastavil na True.

C:\Scripts>Remove-Item * 
What if: Performing operation “Remove File” on Target “C:\Scripts\file1.txt”. 
What if: Performing operation “Remove File” on Target “C:\Scripts\file10.txt”. 
What if: Performing operation “Remove File” on Target “C:\Scripts\file2.txt”. 
(…)

C:\Scripts>$WhatIfPreference 
True

C:\Scripts>$WhatIfPreference = $false 
C:\Scripts>Remove-Item * 
C:\Scripts>ls | select name | fw -c 5

Poznámka: Pokud chcete některému z kolegů trošku ztížit práci v PowerShellu, myslím že vložení řádky $WhatIfPreference = $true do jeho profilu může být docela legrace. Jestli nečte TechNet Flash, tak se možná na chvilku zapotí J

Samozřejmě by nedávalo smysl, abyste před každým voláním Remove-Item (a podobných) vraceli hodnotu proměnné WhatIfPreferencezpátky na false. Pomocí následujícího zápisu změníte hodnotu jednorázově.

C:\Scripts>$WhatIfPreference 
True

C:\Scripts>Remove-Item * -WhatIf:$False 
C:\Scripts>ls 
C:\Scripts>

Tímto bychom ukončili naši miniexkurzi do tajů funkcí. Pokud vás zaujalo použití proměnné WhatIfPreference doporučuji k přečtení tématickou nápovědu about_preference_variables.

Seriál Windows PowerShell: Skripty a moduly (část 13.)

Další možností, jak uchovat naše PowerShellí výtvory pro budoucí generace jsou mimo funkcí (probraných v posledních dvou dílech) také skripty a moduly. Dnes si o nich něco povíme.

Skripty

Pokud máte vytvořeno více funkcí, můžete (a zřejmě i budete) je sdružovat do skriptů. Skript může být opět záležitostí na jednu řádku, ale pravděpodobněji budete vytvářet skripty o něco složitější. Skript je v podstatě kus kódu uložený do souboru s příponou PS1. Již v prvním díle tohoto seriálu jsme si řekli základní informace o spouštení funkcí, proto je již nebudeme opakovat.

C:\Scripts> ‘Get-Process | Sort-Object Name | Select-Object -First 5’ > skript1.ps1 
C:\Scripts> .\script1.ps1 
Handles     NPM(K)      PM(K)      WS(K)      VM(M)      CPU(s)     Id      ProcessName 
——-     ——      —–      —–      —–      ——     —      ———– 
42                3      1224        3804         33     0,14     2240      AESTFltr 
39                2       964        2480         20     0,08     4056      ApMsgFwd 
41                2       948        2932         29     0,06     1680      ApntEx 
88                3      2028        5780         37     1,02      576      Apoint 
161               4      3480        5056         39     209,06   2156      BbDevMgr

Právě jsme vytvořili první skript, prostým zkopírováním příkazů do textového souboru. Tento soubor jsme spustili a dostali jsme naprosto stejné výsledky jako bez použití skriptu. Až potud žádné překvapení, pojďme dále.

C:\Scripts>$processCount = (Get-Process | Measure-Object).Count 
C:\Scripts>$processCount 
88

C:\Scripts> @’ 
>> $pc = (Get-Process | Measure-Object).Count 
>> Write-Host $pc 
>> ‘@ > script2.ps1

C:\Scripts>.\script2.ps1 
88

C:\Scripts> $pc 
C:\Scripts>

Vidíme, že proměnná pc neobsahuje žádnou hodnotu. Přesto skript proběhl, protože Write-Host nám počet procesů vypsal. Zde vstupuje do hry oblast platnosti proměnných (anglicky scope). Stručně řečeno, proměnné můžeme vytvářet tak, že budou „viditelné“ (uvidíme jejich hodnoty) pouze ve funkci, skriptu nebo globálně. Pokud neuvedeme výslovně oblast, platí všechny proměnné, vytvořené ve skriptu, pouze uvnitř tohoto skriptu a „zvenku“ (konzole) je nemůžeme přečíst. Což byl přesně předchozí případ. Proměnná pc vznikla uvnitř skriptu, cmdlet Write-Host ji vypsal na konzoli (uvnitř skriptu) a po jeho skončení zanikla i tato proměnná. Máme několik možností, jak tuto vlastnost obejít.

Uvedení platnosti proměnné v jejím názvu

Nejdříve opět předvedeme a poté si techniku okomentujeme.

C:\Scripts> @’ 
>> $Global:pc = (Get-Process | Measure-Object).Count 
>> Write-Host $Global:pc 
>> ‘@ > script3.ps1

C:\Scripts> .\script3.ps1 
88

C:\Scripts> $pc 
88

Skript je stejný, ale před vlastním jménem proměnné jsme uvedli modifikátor Global. Tím určujeme, že proměnná bude platit globálně a tedy i v konzoli.

Dot-sourcing

Druhou možností je takzvaný dot-sourcing (nebudu se pouštět do čekého překladu  Pomocí tečky (.) určíme, že skript má „proběhnout globálně“ Tím zajistíme, že všechny proměnné zůstanou viditelné globálně i po skončení vlastního skriptu.

Nejprve smažeme proměnnou pc, která už globálně existuje.

C:\Scripts> Remove-Variable pc 
C:\Scripts> $pc 
C:\Scripts>

A nyní spustíme znovu druhý skript, který nám dříve „nefungoval“.

C:\Scripts> . .\script2.ps1 
89

C:\Scripts> $pc 
89

Všimněte si tečky uvedené před voláním skriptu. Ta nám zajistí dot-sourcing.

Pokud se ptáte, jestli je možné u funkcí použít parametry, odpověď je ano. Pro parametry a nápovědu platí stejná pravidla jako pro funkce.

Profil

Pokud budete pracovat v PowerShellu delší dobu, začnete si možná upravovat prostředí tak, aby vám více vyhovovalo. Ať již se jedná a vytváření vlastních aliasů, definici proměnných nebo nebo například o vlastní skripty, může se hodit, mít je v konzoli okamžitě připravené k použití. Uveďme si příklad. Často pracujete s měnami a hodilo by se vám, kdybyste měli funkci na převod mezi dolary a korunami jednoduše dostupnou.

C:\Scripts> @’ 
>> function Get-Dolar 
>> { 
>> param([int]$castka) 
>> Write-Output $($castka/18) 
>> } 
>> ‘@ > get-dolar.ps1

Skript spustíme pomocí dot-sourcingu (jinak by se nám funkce „neobjevila“ s globální platností a můžeme převádět koruny na dolary (prosím teď neřešme funkci jako takovou – jistě je na ní mnoho co vylepšovat).

C:\Scripts > . .\get-dolar.ps1 
C:\Scripts > Get-Dolar 72 
4

Vidíme, že funkce funguje a můžeme ji používat. Při dalším spuštění PowerShellu budeme ovšem muset opět zavolat skript, abychom mohli funkci použít. V tomto případě přichází na řadu profil. Stručně řečeno je profil skript, který se spouští při startu PowerShellu. Na vašem počítači je uložen v:

C:\Scripts> $PROFILE.AllUsersAllHosts 
C:\WINDOWS\system32\WindowsPowerShell\v1.0\profile.ps1

Standardně není vytvořený a pokud jej nemáte stačí jej vyrobit například v notepadu. V okamžiku, kdy máte profil vytvořený, můžete do něj dávat např. funkce, které často využíváte. Pojďme si tedy takový profil vytvořit.

C:\Scripts> gc $PROFILE.AllUsersAllHosts 
Get-Content : Cannot find path ‘C:\WINDOWS\system32\WindowsPowerShell\v1.0\profile.ps1’ because it does not exist. 
At line:1 char:3 
+ gc <<<< $PROFILE.AllUsersAllHosts 
+ CategoryInfo : ObjectNotFound: (C:\WINDOWS\syst…1.0\profile.ps1:String) [Get-Content], ItemNotFoundException 
+ FullyQualifiedErrorId : PathNotFound,Microsoft.PowerShell.Commands.GetContentCommand

C:\Scripts> @’ 
>> function Get-Dolar 
>> { 
>> param([int]$castka) 
>> Write-Output $($castka/18) 
>> } 
>> ‘@ > $PROFILE.AllUsersAllHosts 
>>

C:\Scripts> gc $PROFILE.AllUsersAllHosts 
function Get-Dolar 
{ 
param([int]$castka) 
Write-Output $($castka/18) 
}

Potřebnou funci máme uloženou. Nyní je potřeba znovu spustit PowerShell. Po spuštění můžeme vyzkoušet naši známou konverzi.

C:\Scripts> Get-Dolar 72 4

Více o profilech se můžete dočíst v tématické nápovědě about_Profiles. Důležité je například to, že profil není pouze jeden nebo že profily jsou uloženy v různých cestách.

Moduly

Po funkcích a skriptem postoupíme do dalšího levelu a podíváme se na moduly. Zde si dovolím malou odbočku. Několik let zpátky jsem se staral o systém jehož výstupem bylo velké množství různých log souborů. Vzhledem k tomu, že LogParser byl v té době hudbou budoucnosti, hledal jsem možnosti, jak tyto logy prohledávat. Nakonec jsem skončil u jazyka Perl. Vzhledem k tomu, že se mé skripty rozrůstaly a komplexnost se zvětšovala, potřeboval jsem stále dokonalejší techniky. A tehdy příšel na řadu CPAN – zdroj stovek skriptů od různých autorů pokrývajících snad všechny myslitelné oblasti. Stačilo jen najít správný skript (modul) a „doinstalovat“ jej do mého prostředí. CPAN dává jako příklad i Bruce Payette ve své knize PowerShell in Action. Idea modulů je tedy jednoduchá – umožnit různým autorů vytvářet „skripty“ které budou snadno přenositelné mezi počítači a pro složitější úkony budou poskytovat větší funkcionalitu než skripty. V PowerShellu v1 bylo jediným možným rošířením použití tzv. snap-inů. Například vynikající cmdlety pro správu Active Directory od firmy Quest byly poskytovány ve formě snap-inů (tedy v podobě DLL souborů). V současné době je velké množství rozšíření PowerShellu poskytováno ve formě modulů (tedy text). Moduly ovšem mohou být i binární, více viz dále. Nejdříve si ukážeme práci s již existujícími moduly a poté si ukážeme, jak vytvořit moduly vlastní. Kontrolní otázka: Zkuste si tipnout – jaký cmdlet použít pro zjištění dostupných modulů? Pokud jste odpověděli Get-Module, máte samozřejmě pravdu. Pojďme si ukázat příkazy, které použije při práci s moduly. Opět nejdřív ukážeme celý kód a poté jej okomentujeme.

C:\Scripts> Get-Module 
C:\Scripts> Get-Module -ListAvailable

ModuleType Name ExportedCommands 
———- —- —————- 
Script Cookbook {} 
Script CP2010 {} 
Script DotNet {} 
Manifest FileSystem {} 
Script ISEDemo {} 
Manifest IsePack {} 
Manifest PowerShellPack {} 
Manifest PSCodeGen {} 
Manifest Pscx {} 
Manifest PSImageTools {} 
Manifest PSRemoteRegistry {} 
Manifest PSRSS {} 
Manifest PSSystemTools {} 
Manifest PSUserTools {} 
Manifest SMS2003 {} 
Manifest TaskScheduler {} 
Manifest WPK {} 
Manifest BitsTransfer {}

C:\Scripts> Import-Module PSRemoteRegistry 
C:\Scripts> gmo

ModuleType Name ExportedCommands 
———- —- —————- 
Script PSRemoteRegistry {Get-RegKey, Get-RegBinary, Get-RegQWord, Get-RegMultiString…}

C:\Scripts> ipmo BitsTransfer 
C:\Scripts> ipmo wpk 
C:\Scripts> gmo

ModuleType Name ExportedCommands 
———- —- —————- 
Script PSRemoteRegistry {Get-RegKey, Get-RegBinary, Get-RegQWord, Get-RegMultiString…} 
Manifest bitstransfer {Start-BitsTransfer, Remove-BitsTransfer, Resume-BitsTransfer, Get-BitsT… 
Script wpk {Get-DependencyProperty, New-ModelVisual3D, New-DiscreteVector3DKeyFrame… 
C:\Scripts> Remove-Module ps* 
C:\Scripts> rmo b* 
C:\Scripts> New-Label “$((gmo).name)” -show

C:\Scripts> gmo|rmo 
C:\Scripts> gmo

Jak jsme již řekli, pro zobrazení instalovaných modulů slouží cmdlet Get-Module zadaný bez parametrů. Jelikož nebyl žádný modul použit, nezobrazilo se ve výpisu nic. Proto jsme použili parametr ListAvailable. Při jeho použití se PowerShell podívá do všech adresářů s moduly (adresáře jsou uvedeny v proměnné prostředí $env:PSModulePath) a vypíše moduly, které můžeme importovat. Abychom moduly mohli použít, musíme je importovat pomocí Import-Module. Poté je můžeme použít, respektive můžeme volat funkce (nebo cmdlety) v nich obsažené. Zde ukázáno na příkladu modulu WPK (součást Windows PowerShell Pack – více viz 9. část tohoto seriálu). Na konci práce můžeme modul odebrat pomocí Remove-Module. Další příkazy pro práci s moduly (včetně aliasů) můžete zobrazit například takto:

C:\Scripts> gcm *module* -C cmdlet | sort name |% {“{0} {1}” -f $_.Name, $(gal -def $_.Name -ea 0)} 
Get-Module gmo 
Import-Module ipmo 
New-Module nmo 
New-ModuleManifest 
Remove-Module rmo 
Test-ModuleManifest

A jako vždy – podrobnější informace o práci s moduly najdete v tématické nápovědě about_modules.

Seriál Windows Powershell: Tipy a triky – mapy (část 14.)

Programátorům a administrátorům, kteří objevili možnosti .NETu, PowerShell nabízí možnosti, jak rychle prozkoumat neznámé API. Dnes si ukážeme, jakým způsobem bychom mohli postupovat v případě, že bychom si chtěli osahat kontrol na zobrazování map, GMap.NET – Great Maps for Windows Forms & Presentation. Pro jednoduchost si vybereme kontrol pro Windows Forms. Výsledkem pak bude malá aplikace, která nám vrátí GPS souřadnice vybraného místa.

Poznámka: Příklad bude běžet v pořádku pouze pokud bude PowerShell spuštěn v režimu STA. Při spuštění PowerShellu tedy nezapomeňte na přepínač -sta.

V průběhu se seznámíme s některými tipy na práci s enumy, [out] parametry a jak zapisovat handlery k událostem.

Kostra

Budeme potřebovat Form objekt, který bude mapový kontrol obsahovat:

Add-Type -AssemblyName System.Windows.Forms

$f = New-Object System.Windows.Forms.Form

$f.Size = New-Object System.Drawing.Size 700,500

... místo pro další kód

[void]$f.showdialog()

Programátoři zřejmě nic nového neobjevili, tento kód se opakuje pokaždé, když chceme psát WinForms aplikaci. 
Dále si potřebujeme stáhnout příslušné assembly a načíst je. V našem případě půjde o tři assembly, které najdete v příloze. Samozřejmě si je můžete stáhnout i z výše uvedené adresy.

# assembly máme uložené v adresáři lib, načteme je všechny takto:

gci g:\lib\ *.dll | % { Add-Type -path $_.FullName }

Závislosti mezi assemblies

Pokud byste potřebovali najít “ty správné” assemblies, které máte načíst, čtěte dál. Jinak můžete pokračoval dál k vytváření kontrolů.

Assembly, kterou musíte načíst, najdete podle projektu. My budeme používat GMapControl. Rychle proletíme adresářovou strukturu (autor používá zásadu co třída, to nový soubor) a zjistíme, že kontrol se nachází v projektu GMap.NET.WindowsForms. Poté vyhledáme *.csprojsoubor a v něm element AssemblyName. Tak jsme zjistili, že kontrol se kompiluje do assembly GMap.NET.WindowsForms.dll. 
Našli jsme první assembly, kterou určitě načíst musíme. Stejně tak ale budeme pravděpodobně potřebovat i další assembly, na kterých tato závisí. Na závislosti se můžeme podívat přes Reflector, ale stejně dobrou práci zvládne i PowerShell.

PS> $assembly = [reflection.assembly]::LoadFile('g:\lib\GMap.NET.WindowsForms.dll')

PS> $assembly | fl

CodeBase               : file:///g:\lib\GMap.NET.WindowsForms.dll

EntryPoint             :

EscapedCodeBase        : file:///g:\lib\GMap.NET.WindowsForms.dll

FullName               : GMap.NET.WindowsForms, Version=1.0.0.0, Culture=neutral, PublicKeyToken=b85b9027b614afef

GlobalAssemblyCache    : False

HostContext            : 0

ImageFileMachine       :

ImageRuntimeVersion    : v2.0.50727

Location               : g:\lib\GMap.NET.WindowsForms.dll

ManifestModule         : GMap.NET.WindowsForms.dll

MetadataToken          :

PortableExecutableKind :

ReflectionOnly         : False

Properties assembly jsme sice ještě nezjistili, ale zajímavá může být určitě informace o FullName. Ta se vyplatí v případě, kdy nám runtime hlásí, že nemůže načíst nějakou assembly. Je pravděpodobné, že se mu snažíme podstrčit špatnou verzi. Všimněte si takéImageRuntimeVersion – ta nám říká, že assembly byla překompilována pro runtime 2.0. Pro aplikace pod .NET 4.0 pak budete potřebovat zřejmě jinou verzi assembly. PowerShell ovšem stále běží na .NET 2.0/3.5, tedy pro naše potřeby máme verzi správnou.

Vraťme se zpátky. Když předhodíme $assembly commandletu Get-Member -membertype method, zjistíme metody, které nám nabízí. Pro stručnost už je zde nebudu uvádět. Ta správná metoda, která nám zjistí, na kterých ostatních assemblies ta naše závisí, se skrývá pod jménem …

PS> $assembly.GetReferencedAssemblies()

Version        Name

-------        ----

2.0.0.0        System.Windows.Forms

2.0.0.0        mscorlib

1.5.3.3        GMap.NET.Core

2.0.0.0        System

2.0.0.0        System.Drawing

Víme tedy, že assembly GMap.NET.Core budeme potřebovat načíst také. A když se podíváme na ni …

PS> $assembly2 = [reflection.assembly]::LoadFile('g:\lib\GMap.NET.Core.dll')

PS> $assembly2.GetReferencedAssemblies()

Version        Name

-------        ----

...

1.0.66.0       System.Data.SQLite

Zjistili jsme závislost na System.Data.SQLite. Z tohoto důvodu jsou všechny tyto tři assembly přibaleny k tomuto článku a výše je načítáme pomocí příkazu:

gci .. | % { Add-Type .. }

Vytvoření kontrolek

Na oficiálních stránkách bohužel mnoho dokumentace není. Inspirovat se můžeme převážně jen z demo aplikace, která je mimochodem dostupná pro Windows Forms i WPF. Zkopírujeme si základní kód na inicializaci kontrolu:

$map = New-Object GMap.NET.WindowsForms.GMapControl

$map.Anchor = 'top', 'bottom', 'left', 'right'

$map.Location = New-Object System.Drawing.Point 0,0

$map.MapType = 'GoogleMap'

$map.MarkersEnabled = $true

$map.MaxZoom = 17

$map.MinZoom = 2

$map.MouseWheelZoomType = 'MousePositionAndCenter'

$map.ShowTileGridLines = $false

$map.Size = new-object System.Drawing.Size 700, 500

$map.Zoom = 16

$map.Position = new-object GMap.NET.PointLatLng 50.207, 16.849

Povšimněte si properties Anchor, MapType a MouseWheelZoomType. PowerShell nám velmi pomáhá, při práci s enumy. Pokud se snažíme přiřadit do proměnné typu enum hodnotu typu string, PowerShell ji automaticky zkonvertuje na příslušný enum. Když přiřazujeme pole stringů a daný enum má přiřazený atribut [FlagsAttribute], pak všechny stringové hodnoty jsou zkonvertovány na enumové hodnoty a následně kombinovány dohromady. Můžete si to ověřit například takto: $map.Anchor -band [system.windows.forms.anchorstyles]::right.

Abychom si mohli přepínat mezi více typy map, přidáme si ještě na formulář combo box. Ten bude reagovat na změnu indexu a nastaví příslušný typ mapy do objektu $map:

$change = new-object System.Windows.Forms.ComboBox

$change.Anchor = 'top', 'right'

$change.Location = New-Object System.Drawing.Point 615,0

$change.DropDownStyle = 'DropDownList';

$change.FormattingEnabled = $true;

$change.Items.AddRange(@('GoogleMap', 'GoogleSatellite', 'GoogleTerrain', 'GoogleHybrid'))

$change.Size = new-object System.Drawing.Size(80, 21);

$change.TabIndex = 2;

$change.add_SelectedValueChanged({ $map.MapType = $change.SelectedItem })

$change.SelectedIndex = 1

Hodnoty GoogleMap až GoogleHybrid jsou opět hodnoty enumu. Jak zjistíme dostupné hodnoty? Například takto:

PS> $map.MapType.gettype().fullname

GMap.NET.MapType

PS> [enum]::getnames([GMap.NET.MapType])

None

GoogleMap

GoogleSatellite

GoogleLabels

GoogleTerrain

GoogleHybrid

GoogleMapChina

GoogleSatelliteChina

GoogleLabelsChina

GoogleTerrainChina

GoogleHybridChina

....

K hodnotám enumu se přistupuje – pokud nemůžeme zrovna použít automatické konverze ze stringu – jako k statickým properties. Tedy jméno enumu uzavřeme do hranatých závorek a k hodnotám se dostaneme přes dvojtečkovou notaci, viz. příklad s AnchorStyles:[system.windows.forms.anchorstyles]::right

Možná jste si všimli, jakým způsobem definujeme handler pro událost SelectedValueChanged – voláme metodu se jménem add_jmeno-udalosti a jako parametr předáváme scriptblock, který se má vykonat. Handlery mívají dva parametry, které se často ale ani nevyužijí, jako v tomto případě. Pokud byste přesto potřebovali jeden z nich přečíst, níže je zobrazen handler na událost Click, kde se získává aktuální pozice myši.

Můžeme si vyzkoušet, jestli bylo naše dosavadní snažení k něčemu dobré. Kontroly vložíme do kolekce a zobrazíme formulář.

$f.Controls.Add($change)

$f.Controls.Add($map)

[void]$f.showdialog()

Naši malou aplikaci teď můžeme spustit. Rolováním kolečka myši měníme zoom. Klikem pravým tlačítkem a tažením pak posouváme výřez.

Vidíme, že vcelku zadarmo jsme získali aplikaci, která je schopna bez prohlížeče zobrazovat mapy a dokonce je cachovat. Vnitřně totiž používá SQLite, kde si uchovává stažené náhledy a funguje tak i v případě, že zrovna není dostupné síťové připojení.

Přidání křížku

Pokud chceme ještě přidat na mapu značku, kterou bychom zacílili na námi vybraný bod, potřebujeme přidat vrstvu a do ní značku zasadit:

$overlay = New-Object GMap.NET.WindowsForms.GMapOverlay $map, "point"

$map.Overlays.Add($overlay)

$marker = New-Object GMap.NET.WindowsForms.Markers.GMapMarkerCross($map.Position)

$overlay.Markers.Add($marker)

Na mapě se nám tak bude zobrazovat červený křížek. Při kliku chceme, aby se křízek přesunul na místo, kam jsme kliknuli. To docílíme opět zavěšením na události Click.

$map.add_Click({

param($s, $e)

$marker.Position = $map.FromLocalToLatLng($e.X, $e.y)

$map.Tag = $marker.Position.Lat,$marker.Position.Lng

})

Všimněte si, že tentokráte jsme použili scriptblock s parametry. Druhý parametr obsahuje umístění myši v okamžiku kliknutí. Podle nich nastavíme červenému křížku nové souřadnice a uložíme je do property $map.Tag.

Poté, co zavřeme formulář, budeme mít v property Tag poslední kliknuté souřadnice. Přečteme je tedy a vrátíme jako výsledek skriptu. Poslední řádek skriptu tedy bude:

$map.Tag

Nastavení počátečních souřadnic

Ve skriptu máme nyní počáteční souřadnice nastavené napevno. My ovšem máme i možnost si souřadnice vyhledat. Níže uvedený kód vložte kdekoliv za inicalizaci mapového kontrolu a před zobrazení formuláře:

[GMap.NET.GeoCoderStatusCode]$status = 'G_GEO_SUCCESS'

$loc = [GMap.NET.GMaps]::Instance.GetLatLngFromGeocoder("Kralický sněžník", [ref] $status);

if ($status -eq 'G_GEO_SUCCESS') {

Write-Host "Nalezen Kralický Sněžník, souřadnice: $($loc.Lat), $($loc.Lng)"

$lat,$lng = $loc.lat,$loc.Lng

$map.Position = new-object GMap.NET.PointLatLng $lat, $lng

} else {

$lat,$lng = 49.6034664,17.254005

}

Zde si povšimněte použití metody GetLatLngFromGeocoder. Druhý parametr by měl být předáván jako [out]. Jenže PowerShell nic takového nezná. V PowerShellu se oba případy ([ref] i [out]) předávají jako [ref]. Příklad můžete vidět například na http://wiki.poshcode.org.

Někdy se nám může hodit, když známe, jak zapsat typovou proměnnou: [GMap.NET.GeoCoderStatusCode]$status. Takovým způsobem určíme typ proměnné $status, který zaručuje, že do proměnné vždy můžeme uložit pouze hodnotu typu[GMap.NET.GeoCoderStatusCode]. Opět platí, že pokud se snažíme do ní uložit stringovou hodnotu, je tato hodnota konvertována a v případě úspěchu uložena. Můžeme si to ukázat na tomto příkladu:

[GMap.NET.GeoCoderStatusCode]$status = 'G_GEO_SUCCESS'

$status = 'test' #chyba

Cannot convert value "test" to type "GMap.NET.GeoCoderStatusCode" due to invalid enumeration values.....

$status = 'G_GEO_TOO_MANY_QUERIES' #uspěje

Povedlo se?

S trochou štěstí jste se dostali až k opravdu funkčnímu kódu a dozvěděli se pár drobných triků, které vám mohou pomoci programovat téměř jako v C#. Opravdu jen téměř. Nezapomínejme totiž, že PowerShell je primárně skriptovací jazyk, který rozhodně nemá ambice stát se plnohodnotným objektově orientovaným jazykem.

Seriál Windows Powershell: Moduly (část 15.)

Při našem posledním setkání jsme si ukázali úvod do modulů. Naučili jsme se, jak je importovat do PowerShellu a jak zjistit, které moduly máme již importované. Zajisté jste dali na mou radu a přečetli si tématickou nápovědu about_modules J Dnes si ukážeme, jak vytvořit modul vlastní.

Nejdříve si „hodíme“ potřebné příkazy do konzole: 
PS C:\> $wc = New-Object Net.WebClient 
PS C:\> $link = ‘http://www.cnb.cz/cs/financni_trhy/devizovy_trh/kurzy_devizoveho_trhu/denni_kurz.txt’ 
PS C:\> $wc.DownloadFile($link, ‘C:\Scripts\kurzy\kurzy.txt’) 
PS C:\> gc ‘C:\Scripts\kurzy\kurzy.txt’ |? { $_ -match ‘EUR’ } |% { $_ -match ‘\|(?<kurz>\d{2}.\d{1,3})$’|Out-Null; [double]$matches.kurz.replace(‘,’, ‘.’)

25,01

Na první řádce vytvoříme objekt WebClient. Pomocí tohoto objektu můžeme stahovat data z dané webové stránky (velmi, velmi zjednodušeně řečeno – tato třída toho umí daleko více, ale pro nás je momentálně důležité, že máme proměnnou, pomocí které můžeme stáhnout text dané stránky). Do proměnné $link si uložíme cestu, ze které budeme stahovat daný soubor (podle cesty je zřejmé, že nám půjde o kurzy měn na stránkách ČNB). Na třetím řádku použijeme metodu DownloadFile a uložíme daný soubor na lokální disk. Na posledním řádku už pouze filtrujeme ze souboru potřebné údaje – pro filtrování jsme použili regulární výraz (o regulárních výrazech si povíme v některém z dalších pokračování). Na posledním řádku už je vidět kurz pro aktuální den.

Je vidět, že jsme obdrželi požadovaná data, ale k dokonalosti nám samozřejmě hodně chybí. Pokud budeme chtít spustit stejné příkazy zítra, nebude příliš efektivní přepisovat celý kód znovu. Proto by se nám hodilo uložit všechny potřebné příkazy do jednoho souboru. Mohli bychom použít skript, ale pro studijní účely si vytvoříme modul. Tento modul bude obsahovat funkci pro stažení kurzů z webu, funkce pro přepočet z EUR a USD, potřebné aliasy. Modul nazveme Kurzy.

Nejprve si zobrazíme aktuální moduly začínající na ‘k’.

PS C:\> Get-Module k* -list

Žádný takový modul neexistuje. V minulém díle jsme uváděli, že moduly jsou uloženy v adresářích uložených v proměnné prostředíPSModulePath.

PS C:\Scripts\kurzy> $env:PSModulePath -split ‘;’ 
C:\Documents and Settings\moravec\My Documents\WindowsPowerShell\Modules 
C:\WINDOWS\system32\WindowsPowerShell\v1.0\Modules\ 
Dropbox:\PowerShell\Profile

První dvě cesty jsou standardní – pro konkrétního uživatele a pro všechny uživatele na počítači. Vidíte, že na svém počítači jsem přidal ještě třetí cestu a využívám Dropbox – tím mám zajištěno, že všechny moduly, které potřebuji na svých počítačích, mám stále dostupné. Ukažme si, co obsahuje první adresář:

PS C:\> ls ($env:PSModulePath -split ‘;’)[0] |? {$_.PsIsContainer} | Format-Wide Name -Column 3 
Add-on.AuthoringToolkit Add-on.BlueConsole Add-on.ExpandAlias 
Add-on.HelpBrowser Add-on.ModuleManagement Add-on.NumberedBookmarks 
Add-on.PowerGUIOnline Add-on.ScriptEditorEssentials Add-on.ScriptSigning 
Add-on.TestAddOn adoLib Agent 
CP2010 DemoPowerShell DotNet 
FileSystem ISECreamBasic IsePack 
MetaProgramming OracleClient OracleIse 
PBM PoShTD PowerBoots 
PowerShellPack PowerTab PSCodeGen 
Pscx Pscx_old PSImageTools 
PSRemoteRegistry PSRSS PSSystemTools 
PSUserTools Repl Setup 
ShareUtils ShowMbrs SMS2003 
SQLIse SQLMaint SQLParser 
SQLPSX SQLServer SSIS 
TaskScheduler WPK

Poznámka: V tuto chvíli byste již měli rozumět celé konstrukci. Jediný možný zádrhel se vám může stát při zkoumání konstrukce |? {$_.PsIsContainer} – jedná se o filtrování pouze adresářů.

Každý modul je uložen v samostatném adresáři a je tvořen (minimálně) souborem stejného jména. Vytvořme si tedy základ pro náš modul.

PS C:\> mkdir (Join-Path ($env:PSModulePath -split ‘;’)[0] Kurzy) 
PS C:\> cd (Join-Path ($env:PSModulePath -split ‘;’)[0] Kurzy) 
PS C:\Documents and Settings\moravec\My Documents\WindowsPowerShell\Modules\Kurzy> “” > Kurzy.psm1 
PS C:\Documents and Settings\moravec\My Documents\WindowsPowerShell\Modules\Kurzy> Get-Module k* -List 
ModuleType Name ExportedCommands

———- —- —————-

Script Kurzy {}

Nejprve jsme vytvořili adresář, poté soubor s příponou PSM1 (PowerShell Module) a pak jsme si ověřili, že náš modul existuje a je „viditelný“. Samozřejmě zatím nic neumí. Přepíšeme tedy náš původní kód do trošku čitelnější podoby a vložíme jej do souborukurzy.psm1.

function Get-CNBExchangeRate 
{ 
$wc = New-Object Net.WebClient 
$link = ‘http://www.cnb.cz/cs/financni_trhy/devizovy_trh/kurzy_devizoveho_trhu/denni_kurz.txt’ 
$file = ‘C:\Scripts\kurzy\kurzy.txt’ 
$wc.DownloadFile($link, $file) 
} 
function Get-Kurz { 
param([string]$kod) 
Get-CNBExchangeRate 
$file = ‘C:\Scripts\kurzy\kurzy.txt’ 
$pattern = ‘\|(?<kurz>\d{2}.\d{1,3})$’ 
gc $file |? 
{ $_ -match $kod } |% 
{ $_ -match $pattern | Out-Null; [double]$matches.kurz.replace(‘,’, ‘.’) } 
}

function eur {Get-Kurz EUR} 
function usd {Get-Kurz USD}

Vše jsme rozdělili do dvou hlavních částí (funkcí). První funkce stáhne soubor s kurzy do daného adresáře a druhá provede vlastní konverzi na základě dané měny (určené parametrem $kod). Funkce eur a usd nám slouží pouze pro rychlejší zobrazení požadované hodnoty.

PS C:\Documents and Settings\moravec\My Documents\WindowsPowerShell\Modules\Kurzy> cd c:\ 
PS C:\> Import-Module Kurzy 
PS C:\> usd

19,009

PS C:\> Get-Module k* 
ModuleType Name ExportedCommands

———- —- —————-

Script Kurzy {usd, eur, Get-Kurz, Get-CNBExchangeRate}

Po importu modulu můžeme jednoduchým příkazem (funkcí) zobrazit aktuální kurz. Všimněte si, že po dalším volání cmdletu Get-Modulevidíme všechny funkce, které jsme vytvořili. Všechny jsou „exportované“ do aktuálního prostředí PowerShellu a můžeme tedy všechny použít. Pro naše potřeby, ale není nutné používat přímo funkci Get-CNBExchangeRate, protože tato funkce je volána uvnitř funkce Get-Kurz vždy, když je aktuálně zapotřebí. Proto využijeme možnost exportovat pouze funkce, které určíme pomocí cmdletu Export-ModuleMember. Jako poslední řádku našeho modulu přidáme

Export-ModuleMember Get-Kurz, eur, usd 
modul odebereme, opětovně importujeme a vyzkoušíme, zda se změna projevila.

PS C:\> rmo kurzy; ipmo kurzy; gmo k* 
ModuleType Name ExportedCommands

———- —- —————-

Script kurzy {usd, eur, Get-Kurz}

(je to vidět – opravdu mám rád aliasy  Ve sloupci ExportedCommands nyní chybí „nechtěná“ funkce a pokud byste jí chtěli nyní použít, nebude pro vás dostupná.

Pro rychlou konverzi můžeme použít funkce eur a usd a v případě potřeby konverze jiné měny, můžeme použít funkci Get-Kurz. Možná by se nám ale hodilo, vytvořit si pro tuto funkci alias. To můžeme provést přímo v rámci modulu a tím zajistit, že alias se nám vytvoří při importu modulu. Trochu upravíme poslední přidanou řádku a místo ní vložíme následující tři:

Set-Alias kurz Get-Kurz 
Export-ModuleMember -Function Get-Kurz, eur, usd 
Export-ModuleMember -Alias kurz 
Přidali jsme alias a navíc jej i určili pro export. Vše opět ověříme:

PS C:\> rmo kurzy; ipmo kurzy; gmo k* | fl 
Name : kurzy 
Path : C:\Documents and Settings\moravec\My Documents\WindowsPowerShell\Modules\kurzy\kurzy.psm1 
Description : 
ModuleType : Script 
Version : 0.0 
NestedModules : {} 
ExportedFunctions : {eur, Get-Kurz, usd} 
ExportedCmdlets : {} 
ExportedVariables : {} 
ExportedAliases : kurz

Je vidět, že alias se nám opravdu objevil na seznamu. Nyní můžeme využít tento alias pro zjištění kurzu jakékoli jiné měny ze seznamu.

PS C:\> kurz jpy

22,534

Samozřejmě bychom mohli náš modul dále vylepšovat. Nyní nám například funguje pouze pokud nepoužíváme proxy server – v případě, že jej používáme (nebo nejsme připojeni na internet) modul nefunguje, mohli bychom chtít zobrazit seznam možných měn, atd. Pěkné domácí úkoly, že ano?

Závěrem bych chtěl upozornit na jeden užitečný Add-in do PowerGUI Script Editoru. Jmenuje se Module Management a slouží (mimojité) ke konverzi vašich současných skriptů do modulu. Návod na instalaci a použití je dostupný na stránce tohoto Add-inu. Pokud jej budete zkoušet, určitě si všimnete, že kromě souboru s příponou PSM1 (vlastní modul), vytvoří i soubor PSD1. Tento soubor se nazývá manifest a k čemu všemu se dá využít si ukážeme v příští části, kde naše putování po modulech ukončíme. Zároveň si také ukážeme binární moduly a podíváme se na jednu velice užitečnou vlastnost modulů – těšte se :).

Seriál Windows PowerShell: psake (část 16.)

Dnes se podíváme na modul, který se nechal inspirovat z jiných jazyků a používá se nejčastěji na automatizaci buildu (nebudu zde kostrbatě překládát anglické dobře známé pojmy), ale stejně tak dobře najde uplatnění v situacích, kdy potřebujeme provést sekvenci na sobě závislých kroků. Modul si můžete stáhnout z https://github.com/JamesKovacs/psake a již je určitě jasné, že se jmenuje psake.

Proč psake a ne msbuild?

Odpověď je jednoduchá. Pokud rádi editujete xml, pak vám nevadí práce s msbuildem. Pro ostatní psake (respektive PowerShell) nabízí komfort skriptovacího jazyka, kterého jste se v xml museli vzdát. Msbuild má samozřejmě také své přednosti, takže nejlepší volbou je kombinovat psake a msbuild dohromady – jak už to obyčejně na světě bývá.

Krom toho je psake možné použít i pro administrátorské účely. Vše, co nabízí PowerShell, je přístupné v psake. Psake je totiž napsané v PowerShellu. Příklady snad řeknou více.

Jak psake rozchodit

Na domovské stránce https://github.com/JamesKovacs/psake stačí po kliknutí na tlačítko Download zvolit poslední release číslo 4.00. Tento zip soubor pak rozbalte na disk (dále předpokládám adresář c:\psake). Spusťte PowerShell konzoli a pokračujte příkazy:

PS> sl c:\psake

import-module .\psake.psm1

# psake modul je naimportovaný

Get-Help Invoke-psake -Full

Psake je dobře zdokumentovaný modul, takže poslední příkaz vypíše přehled parametrů použitelných při volání Invoke-Psake. Navíc ale obsahuje několik příkladů, na kterých je použití dobře patrné.

Jednoduchý příklad

Pro rychlé uvedení do problematiky si tu ukážeme jednoduchý příklad, jehož cílem je:

1.     Adresář d:\temp\code překopíruje do d:\temp\codebak (pro jednoduchost ne rekurzivně).

2.     Vylistuje seznam souborů z d:\temp\codebak uloží jej do d:\temp\codebak\files.txt.

3.     Spustí příkaz na commit do VCS.

Z popisu jednotlivých kroků je jasné, že po sobě následují. Za jistých okolností se ale může hodit spustit kterýkoliv z příkazů samostatně. V psake skriptu by pak kroky byly popsány pomocí tasks:

task default -depends Full

task Full -depends Backup, ListFiles, Commit

task Backup {

Write-Host Backup

gci d:\temp\code | ? { !$_.PsIscontainer } | copy-Item -destination d:\temp\codebak

}

task ListFiles {

Write-Host Files list

gci d:\temp\codebak | Select -exp FullName | sc d:\temp\codebak\files.txt

}

task Commit {

Write-Host Commit

start-Process GitExtensions.exe -ArgumentList commit, d:\temp\codebak

}

Tento skript pak uložíme jako psake-build.ps1 a spustíme. Pokud neuvedeme jméno tasku, psake použije task se jménem default:

PS> Invoke-psake -buildFile d:\temp\psake\psake-build.ps1

Executing task: Backup

Backup

Executing task: ListFiles

Files list

Executing task: Commit

Commit

Build Succeeded!

----------------------------------------------------------------------

Build Time Report

----------------------------------------------------------------------

Name      Duration

----      --------

Backup    00:00:00.1396781

ListFiles 00:00:00.0548712

Commit    00:00:00.3255901

Full      00:00:00.5288634

Total:    00:00:00.6099274

A po skončení “buildu” se otevře okno GitExtensions se změnami do VCS. Slovo build se prolíná celým psake, ale znovu podotýkám, že nejde pouze o build. V příkladu jsme nic nepřekládali a nevyvíjeli.

V případě, že bychom potřebovali zavolat pouze některé tasky, specifikujeme je pod parametrem -taskList:

PS> Invoke-psake -buildFile d:\temp\psake\psake-build.ps1 -task Backup, Commit

Pokud dojde v některém kroku k chybě, následující kroky již nejsou vykonány. Jednoduše toho docílíme například kopírováním z neexistujícího adresáře: $codeDir = 'd:\temp\doesntexist':

PS> Invoke-psake d:\temp\psake\psake-build.ps1

Executing task: Backup

Backup

psake-build.ps1:Cannot find path 'D:\temp\doesntexist' because it does not exist.

V případě, že bychom chtěli pokračovat navzdory chybám zaznamenaným při běhu tasku, můžeme toto u tasku určit parametrem -ContinueOnError:

PS> Invoke-psake d:\temp\psake\psake-build.ps1

Executing task: Backup

Backup

----------------------------------------------------------------------

Error in Task [Backup] Cannot find path 'D:\temp\doesntexist' because it does not exist.

----------------------------------------------------------------------

Executing task: ListFiles

....

Parametrizace

Psake skript je samozřejmě pořád skript napsaný v PowerShellu. Proto můžeme jména adresářů uložit do proměnné, aby byl skript přehlednější. Když se ale podíváme do některých psake skriptů, uvidíme kontstrukci properties { $var1 = 'value'; ... }, co tedy použít?

Pokud jde o konstanty a nebudeme je chtít měnit, můžeme použít kteroukoliv z možností. Pokud bychom ale chtěli ve skriptu definovat default hodnotu nějaké proměnné, použijeme konstrukci properties {... }. Tak později můžeme default hodnotu přetížit pomocí parametru -properties. Soubor psake-build.ps1 by pak vypadal takto:

#fixní proměnná, nedá se měnit jinak než zápisem zde ve skriptu

$codeDir = 'd:\temp\code'

properties {

#měnitelná proměnná

$backupDir = 'd:\temp\codebak'

}

task default -depends Full

task Full -depends Backup, ListFiles, Commit

task Backup {

Write-Host Backup

gci $codeDir | ? { !$_.PsIscontainer } | copy-Item -destination $backupDir

}

...

A při volání bychom použili parametr -properties:

PS> Invoke-psake -buildFile d:\temp\psake\psake-build.ps1 -properties @{ backupdir = 'd:\temp\otherbackdir' }

Všimněte si, že jako hodnotu předáváme hashtable, ne scripblock. Každá položka v hashtable specifikuje proměnnou, která bude vyhodnocena ve stejném scope jako properties {... } v psake skriptu (ale později).

Poznámka: výše uvedené není tak úplně pravda. I v případě, že do build skriptu napíšete $backupdir = 'nejaka default cesta' mimo blok properties { ... }, i této proměnné lze nastavit jiná hodnota z command line Invoke-Psake ... -properties @{backupdir= 'jina cesta'}. Spíše bych ji ale nedoporučil; v pozdějších verzích se může jiným způsobem pracovat se scope proměnných a skript by pak mohl přestat správně fungovat.