PowerShell po polsku

W pierwszej części tego cyklu stworzylismy pracowicie pusty profil, teraz nadeszła pora, by zacząć go wypełniać treścią. Profil może pełnić z całą pewnością masę funkcji, ale jest kilka takich, do których jest wręcz stworzony:

• definiowanie: zmiennych, aliasów, funkcji
• ładowanie modułów i wtyczek
• konfigurowanie środowiska (kolorków, rozmiarów…)

Jak widać potencjalnych możliwości jest sporo. Pytanie tylko: jak daleko się w tym posunąć? Pamiętajmy, że profile będą się ładować zawsze (no… prawie – możemy w powershell.exe i kilku innych hostach wyłączyć ich uruchamianie). Moim zdaniem najwygodniej jest umieścić w profilu tylko to, czego używamy zawsze. To, co w ogóle zmienia nasz sposób pracy z powłoką. To, bez czego jesteśmy niby ryby wyrzucone na brzeg. Więc na pewno znaleźć się tu powinny wszelkie zmiene, których obecność jest nam niezbędna do pracy. Wszystkie aliasy, do których jesteśmy przyzwyczajeni. Wszystkie funkcje, dzięki którym możemy normalnie pracować… Itd, itp, a finał znamy wszyscy. Przez to mamy zawsze masę zbędnych rzeczy poupychanych w szafach, piwnicach i garażach. Jak tego uniknąć? Kilka propozycji:

• od czasu do czasu przeglądać profile i rzeczy używane rzadziej ‘wyrzucać’ do modułu o wszystko-mówiącej-nazwie (np. Profil-Mega-Kobyla)
• jeśli coś używamy bardzo rzadko – zamiast tworzyć funkcję w profilu stwórzmy skrypt i umieśćmy go w jednym z folderów figurujących w naszym $env:PATH
• jeśli jakieś rzeczy używamy bardzo często, ale tworzą jakąś spójną, logiczną całość (np. narzędzia do pracy z AD naszego autorstwa) – stwórzmy dla nich osobny moduł i importujmy go w profilu. Dzięki temu łatwiej nam będzie profilem zarządzać
• jeśli korzystamy z ISE – użyjmy możliwości jakie ono daje i stwórzmy jedną ‘dziewiczą’ zakładkę, która da nam możliwość natychmiastowego rozpoczęcia pracy (moją metodę opisałem na moim blogu po angielsku, z całą pewnością wrócę do tego w kolejnych odcinkach tego cyklu.

Naprawdę, higiena profilu jest bardzo wskazana. I rzecz najważniejsza moim zdaniem: skorzystajmy z możliwości jakie daje nam PowerShell i podzielmy nasze dodatki na poszczególne ‘szczeble’ profilowego drzewka. I tak:

• rzeczy używane wszędzie przez wszystkich (na ogół będą to aliasy, rzadziej pewnie funkcje, lub zmienne) –> AllUsersAllHosts
• ustwienie zmiennych środowiska dla wszystkich w ramach danej konsoli/ hosta (czyli użycie funkcjonalności tegoż, jak stałe menu w ISE czy transkrypt w powershell.exe) –> AllUsersCurrentHost
• nasze własne ustawienia, które przydadzą nam się niezależnie od używanej aktualnie konsoli (np. funkcje, niektóre moduły, aliasy) –> CurrentUserAllHosts
• ustawienia własne pod konkretnego hosta (nasze moduły rozszerzające funkcjonalność ISE, czy używany przez nas moduł do PowerShell.exe, wszelkie kolorki, szmery i bajery, które nikomu prócz nas raczej się nie przydadzą) –> CurrentUserCurrentHost

Co to daje? Jeden punkt zarządzania. Naprawdę, to działa. W moim profilu mam np. funkcję:

function Get-WmiHelp {            
[CmdletBinding()]            
param (            
    [Parameter(ValueFromPipelineByPropertyName=$true, Mandatory=$true)]            
    [Alias('Name')]            
    [wmiclass]$Class            
)            
process {            
    $Class.psbase.Options.UseAmendedQualifiers = $true            
    $Class.psbase.methods | Foreach-Object {             
        New-Object PsObject -Property @{            
            Class = $Class.Name            
            Name = $_.Name            
            Help = ($_.Qualifiers["Description"]).Value            
        }            
    }            
}            
<#
    .SYNOPSIS
        Displays info about methods for a given class.
    .DESCRIPTION
        This function is helper function.
        It gets information about methods in a given class.
        It uses [wmiclass] object to get information.
    .PARAMETER Class
        WMI Class to check for methods & method's help
    .EXAMPLE
        Get-WmiObject -List Win32_Network* | Get-WmiHelp
        Displays all methods for Win32_Network* classes with help.
        
    .EXAMPLE
        Get-WmiHelp -Class Win32_Process
        Display methods and help for Win32_Process
 
#>            
                
}            

Ponieważ działa równie dobrze w każdym z hostów – przechowuję ją w profilu *AllHosts. Dzięki temu jeśli kiedyś zechcę ją zmienić (np. dodać jakiś parametr) będę mógł to zrobić w jednym pliku. I niezależnie od użytego hosta – efekt uzyskam identyczny. To wygodne, dlatego odradzam definiowanie elementów, których funkcjonalność nie jest ściśle związana z bieżącym hostem w $profile. Nigdy nie wiadomo, kiedy będziecie zmuszeni przeskoczyć na innego hosta. 😉 A jaka funkcja kwalifikowałaby się do $profile? Np. ta ma rację bytu tylko w ISE:

            
function Edit-Function {            
            
    [CmdletBinding()]            
    param (            
    [Parameter(Mandatory=$true,             
        HelpMessage='Function name is mandatory parameter.')]            
    [ValidateScript({Get-Command -CommandType function $_})]            
    [string]            
    $Name            
    )            
              
    $file = $psISE.CurrentPowerShellTab.Files.Add()            
    $file.Editor.InsertText("function $name {`n")            
    $file.Editor.InsertText($(Get-Command -CommandType function $name |             
        Select-Object -ExpandProperty definition))            
    $file.Editor.InsertText("}")            
}

Pozwala ona otworzyć dowolną funkcję w części ‘skryptowej’ w sposób, który umożliwia jej prostą modyfikację ad-hoc. Naturalnie, w powershell.exe zaśmiecałaby tylko pamięć. Ale ponieważ takich funkcji (przygotowanych pod ISE) miałem nieco więcej – więc ostatecznie trafiły one do mojego modułu ISEFun, który staram się ciągle rozszerzać i udoskonalać. I zgodnie z tym co pisałem na początku – ładuję w $profile cały moduł. Profil mamy więc gotowy. I tym akcentem zamykam część drugą cyklu. Dalej zajmę się pewnymi trikami, które mogą uczynić profil jeszcze przyjaźniejszym. Skupię się na dwóch domyślnych hostach z tej prostej przyczyny, że z nich najczęściej korzystam. Nie omieszkam też wspomnieć o PowerGUI – tam modyfikacja profilu też ma rację bytu. Ale o tym wkrótce.

~ - autor: Bartek Bielawski w dniu 16 marca, 2011.

Napisane w PowerShell
Tagi: Początki, PowerShell, profile