PowerShell po polsku

Planowałem już od dłuższego czasu skrobnąć kolejną część cyklu o modułach innych niż skryptowe, ale maj przemknął mi przed oczami: najpierw majowe wakacje dzieciaków połączone z podróżą do Ziemi Ojczystej i zwieńczone komunią chrześniaka, dalej drugie urodziny najmłodszej i komunia najstarszej córci i nim zerknąłem w kalendarz – przyszło powoli żegnać się z tym pięknym miesiącem. Pogoda również nie nastrajała „komputerowo”, choć biorąc pod uwagę fakt, że na pisanie czas zwykle znajduję i tak w nocy…

Zamiast więc kolejnej części cyklu słów kilka o tym, na co natknąłem się w zasadzie niedawno, a co może Wam się przydać w trakcie pisania zarówno kompilowanych, jak i skryptowych poleceń.

Aliasy parametrów

Zanim jednak o tym, co nowe – słów kilka o tym, co znam i z czego korzystam od dawna: aliasy parametrów. Deklarujemy je w kilku sytuacjach. Po pierwsze, gdy spodziewamy się, że nasi użytkownicy mogą spodziewać się pewnej nazwy parametru, a dobre praktyki podpowiadają nam nazwę inną. Przykład koronny: ComputerName. W zasadzie powinniśmy stosować go zawsze wtedy, gdy zamierzamy pobrać od użytkownika informację o tym, gdzie nasz kod ma być wykonany (albo jakiego komputera polecenie będzie dotyczyć). Ale w niektórych przypadkach użytkownik (na przykład znający daną technologię i oczekujący występującej w niej terminologii) oczekiwać będzie innej nazwy: ManagementServer, ServerName, NodeName. W takim wypadku warto definiować parametry „poprawnie”, a wszelkie synonimy przekazać jako aliasy.

Drugi przypadek dotyczy szczególnie parametrów dłuższych, lub w przypadku kolizji kilku podobnie brzmiących parametrów. W obu przypadkach alias posłuży nam jako ułatwienie przy pracy interaktywnej. Przykładem takich aliasów będą CN (ComputerName) EA (ErrorAction) czy OV (OutVariable). Warto przy tym wykorzystać powszechną praktykę: w przypadku parametru stanowiącego zlepek kilku słów, dodawać aliasy zbudowane z pierwszych liter w słowach tych występujących: CertificatePath -> CP, UserName -> UN.

Trzeci przypadek związany jest ściśle z potokiem. W przypadku parametrów wykorzystujących powiązanie w oparciu o nazwę właściwości (ValueFromPipelineByProprtyName) aliasy stanowić będą ostatnią „deskę ratunku”. Jeśli więc zależy nam na tym, by parametr naszego polecenia miał „jedyną słuszną nazwę” a jednocześnie chcielibyśmy, by właściwości obiektów do niego przesyłanych miały nazwę nieco inną, to wystarczy jeśli parametr zaopatrzymy w odpowiedni alias.

Prosty przykład funkcji, która w oparciu o dane pobrane z pliku CSV spróbuje nawiązać połączenie z wybranych hostem i zwróci informację o jakości tego połączenia:

function Get-PingStatus {            
    param (            
        [Alias('PC', 'CN', 'Server')]            
        [Parameter(            
            ValueFromPipelineByPropertyName,            
            Mandatory            
        )]            
        [String]$ComputerName            
    )            
            
    process {            
        $params = @{            
            Count = 1            
            ErrorAction = 0            
        }            
        $pingResult = Test-Connection @PSBoundParameters @params            
        [PSCustomObject]@{            
            PC = $ComputerName            
            PingResult = $pingResult.ResponseTime            
        }            
    }            
}            
            
Import-Csv -Path .\PCs.csv | Get-PingStatus

Jak widać, w tym wypadku aliasy zostały dodane dla każdej z wymienionych sytuacji.

Aliasy: inaczej

Tyle powtórki. Ale nie o tym chciałem dziś przede wszystkim napisać. Ostatnio moją uwagę zwrócono na fakt, że atrybut „Alias” przyda nam się nie tylko w przypadku zmiany zachowania parametrów. Ten sam atrybut dodany dla całego bloku parametrów spowoduje, że alias dodany zostanie nie do parametru, a do polecenia. Oczywiście, istnieją przynajmniej dwie inne metody tworzenia aliasów. Skorzystać przy tym możemy z poleceń z rzeczownikiem „Alias” (głownie New-Alias, oraz Set-Alias) oraz z dostawcy/dysku alias. W przypadku ostatnim możliwości mamy dwie: polecenie Set-Content, lub składnia wykorzystująca zapis typowy dla zmiennych (pisałem o takim wykorzystaniu tej składni niedawno). To co mi osobiście podoba się w metodzie wykorzystującej atrybut to fakt, że definicja taka jest w całości „przekazywana” przez definicję naszej funkcji. Może się to okazać przydatne szczególnie tam, gdzie nie mamy dostępu do pełnego języka, a jedynie do definiowania poszczególnych jego elementów (jak pliki konfiguracyjne zdalnych końcówek w ramach PowerShell Remoting). Oprócz tego definiowania wielu aliasów dla pojedynczego polecenia jest dużo bardziej zwięzłe. Cztery sposoby definiowania aliasów w PowerShellu:

function Get-PingStatus {            
    [Alias('gpst')]            
    param (            
        # ...            
    )            
            
    # ...            
}            
            
Set-Alias -Name gpst -Value Get-PingStatus            
Set-Content alias:\gpst -Value Get-PingStatus            
${alias:gpst} = 'Get-PingStatus'

Podobnie jak aliasy parametrów, aliasy poleceń najbardziej przydadzą nam się tam, gdzie nazwa polecenia „poprawna politycznie” nie jest oczywista dla osób znających technologię, bądź w sytuacji, w której chcemy umożliwić skorzystanie ze skróconej wersji naszego polecenia w trakcie pracy interaktywnej. I choć aliasy odradzane są w pisanych przez nas skryptach, to czasem jednak mogą się przydać. Zwłaszcza, gdy polecenie zaczyna nieco przytłaczać swoją długością…

~ - autor: Bartek Bielawski w dniu 31 Maj, 2016.

Napisane w PowerShell
Tagi: aliasy parametrów, aliasy poleceń, aliasy w PowerShellu