PowerShell po polsku

Dziś wracamy do tematu modułów w PowerShellu. Uznałem, że jeśli teraz nie przysiądę i nie dokończę tego cyklu – to nie zrobię tego w najbliższej, dającej się przewidzieć przyszłości. Poprzednio opisałem podstawy tworzenia modułów, dziś – pora na manifest i pliki definiującej typy i format ich wyświetlania.

Manifest to prościutki skrypt PowerShella. W zasadzie zawiera on jedną tablicę skrótów z kluczami odpowiadającymi właściwościom/ ustawieniom modułu. Korzystamy przy tym z rozszerzenia .psd1, które wykorzystywane jest w zasadzie tylko w tym celu.

Nasz manifest

Manifest najprościej jest stworzyć przy pomocy polecenia New-ModuleManifest. Polecenie to spyta nas w zasadzie o wszystkie elementy, które do stworzenia manifestu są niezbędne. Większość kluczy ma dość jednoznaczne nazwy, zatrzymać się chciałbym w zasadzie przy dwóch: TypesToProcess i FormatsToProcess.

Oba klucze przyjmują tablicę stringów, w której zawrzeć możemy ścieżkę do wszystkich plików .ps1xml dotyczących naszego modułu. Pliki te służą definiowaniu dla istniejącego typu (czy to typu “prawdziwego”, czy też “wirtualnego”, stworzonego przez nas na potrzeby modułu) dodatkowych właściwości i metod (TypesToProcess) oraz sposobów wyświetlania (FormatsToProcess). Pliki .ps1xml to całkowicie odrębny temat, w dodatku dość obszerny. W wielkim skrócie można napisać, że są to pliki XML o zdefiniowanym schemacie, dzięki którym możemy “centralnie” przeprowadzać operacje podobne do tych, które wykonujemy przy pomocy poleceń takich jak Format-Table, czy Add-Member.

Manifest pozwoli nam powiązać te pliki z naszym modułem, dzięki czemu obiekty tworzone przy jego pomocy będą wyglądać tak, jak my sobie tego zażyczymy. By jednak obiekty przez nas generowane wyróżnić z tłumu innych, zwłaszcza jeśli nie chcemy dodawać “prawdziwego” typu poleceniem Add-Type, musimy skorzystać z jednej, dość prostej techniki, by nasze obiekty miały stosowną “metkę”.

Pseudo-typ i pliki PS1XML.

Skuteczne korzystanie z plików typów/ formatów wymaga od nas trzech rzeczy. Po pierwsze: funkcje tworzące nasz wymarzony obiekt muszą go odpowiednio “oznakować”:

function Get-Foo {            
param (            
    [Parameter(ValueFromPipeline = $true)]            
    [string]$Bar            
)            
            
process {            
    $Out = New-Object PSObject -Property @{            
        One = 1            
        Two = $Bar            
    }            
    $Out.PSTypeNames.Insert(0,            
        'Typ.Wymarzony'            
    )            
    $Out            
}            
}

Druga rzecz, to dodać ten wirtualny typ do naszych plików PS1XML w odpowiednim miejscu, zarówno w pliku opisującym formatki:

<Configuration>

       <ViewDefinitions>

              <View>

                     <Name>Wymarzony.FT</Name>

                     <ViewSelectedBy>

                           <TypeName>Typ.Wymarzony</TypeName>

                     </ViewSelectedBy>

… jak i pliku opisującym rozszerzenia naszego typu:

<?xml version="1.0" encoding="utf-8" ?>

<Types>

    <Type>

        <Name>Typ.Wymarzony</Name>

        <Members>

Jak widać nie wymagało to wielkiej pracy, a efekt jest zwykle zadowalający. Zamiast dość losowego wyniku i obiektu bez żadnych “specjalnych” właściwości i metod możemy uzyskać zwierza, który wyświetlany będzie w sposób dla nas wygodny i będzie gotowy wykonać dla nas wybrane przez nas zadania:

To wszystko można oczywiście zrobić również bez modułu, ale moduł czyni te operacje o wiele prostszymi i daje nam (przy pomocy pliku manifestu) bardzo dokładną kontrolę.

$Env:PSModulePath czyli o instalacji modułu

Moduły można, jak widać na załączonym zrzucie ekranu, importować bez większego trudu z dowolnego miejsca na dysku. Istnieje jednak zmienna środowiskowa, która definiuje kilka folderów, z których import będzie o wiele prostszy. PSModulePath przypomina nieco zmienną PATH: ma identyczną składnię, lista folderów jest rozdzielona średnikami:

Poprawna struktura:

Ponieważ zdarzyć się może, że zrobimy literówkę w nazwie pliku lub folderu (a raczej ze względu na to, że sam kiedyś zmarnowałem sporo czasu próbując ustalić, czemu jeden z moich modułów nie działał poprawnie) stworzyłem wieki temu funkcję, która sprawdzi poprawność tych nazw i jeśli się na to zdecydujemy – błędy te naprawi. Na tym kończę serię dotyczącą efektywnego PowerShella. Troszkę się zeszło…

~ - autor: Bartek Bielawski w dniu 17 marca, 2012.

Napisane w PowerShell
Tagi: formatowanie, moduły, najlepsze praktyki, Początki