PowerShell po polsku

Przyszła pora by podzielić się spostrzeżeniami po drugiej konkurencji tegorocznych Scripting Games. I znów, podobnie jak poprzednio – ogólne wrażenia są całkiem pozytywne. Oczywiście, nie zabrakło i kwasów – dla korzyści obopólnej wspomnę i jedne, i drugie.

Co Wam wyszło?

Przede wszystkim – wyszły obiekty. Nawet nie wiecie jaka to radość dla mnie widzieć, że coraz mniej jest miłośników bazgrania kolorkami po ekranie… W obu kategoriach większość uczestników miała w zanadrzu jakiś sposób tworzenia własnych obiektów i nie zawahali się go użyć. I choć osobiście mam preferencje w tym zakresie, to niezależnie od użytej metody – to było absolutne minimum. I naprawdę – rzadko kiedy tego minimum brakowało.

Dalej: wykorzystanie nowości z PowerShella v3. Wiele osób korzysta z cmdletów CIM (Get-CimInstance i koledzy) i korzysta z nich świadomie: wiadomo, WSMan na serwerze 2000 nie zadziała, ale wystarczy kazać poleceniom CIM “schylić się” i skorzystać z DCOM, a wszystko będzie tak, jak należy. Cieszy mnie też, że wielu uczestników odrobiło “pracę domową” i leciało z WMI tak, jakby nigdy nie zaszły w nim żadne zmiany. Widziałem nawet skrypt, który sprawdzała konkretne łatki, dzięki którym XP i 2003 mogły dawać pełną informację… Wyśmienite.

A wracając do nowości to nie mogę nie wspomnieć tu o użyciu [PSCustomObject]. Jeśli nie wiecie co to za cudo, to tylko spójrzcie jak w PowerShell 3 można stworzyć własny obiekt z zachowaną kolejnością właściwości (istotne przy tworzeniu raportów):

[PSCustomObject]@{            
    Imię = 'Bartosz'            
    Nazwisko = 'Bielawski'            
    email = 'Bartek.Bielawski@live.com'            
}

Gotowe! Dla mnie to cud, miód i orzeszki. Nie dość, że składnia wybitnie zrozumiała, to jeszcze efekt finalny zgodny z oczekiwaniami. Polecam.

Co jeszcze? W przypadku początkujących korzystanie z tego, co nam dają polecenia. Jeśli Get-WmiObject w swoim parametrze ComputerName wspiera tablicę, to po co przekazywać mu komputery pojedynczo? Wszystko można dość łatwo wrzucić do tego parametru bezpośrednio z pliku:

Get-WmiObject -ComputerName (            
    Get-Content C:\IPList.txt            
) -Class Win32_ComputerSystem

Wprzypadku konkurencji zaawansowanej dodatkowo muszę podkreślić fakt, że większość uczestników doskonale radziła sobie z obsługą poświadczeń (włącznie ze wsparcie dla przekazywanego ciągu znaków), rurki, pomocą, nazewnictwem… W ogóle, aż miło było momentami popatrzeć. Tyle miodu. Pora na drugą stronę medalu.

Co (niektórym) wyszło bokiem?

O poleceniu Write-Host napisano już tyle złego, że każde kolejne zdanie wydaje się już kopaniem leżącego. Ale ponieważ leżący kąsa nas w kostkę, chyba nie ma innego wyboru. Pamiętajcie: Write-Host marnie się sprawdza jako narzędzie do tworzenia raportów. Ani nie da się go przekierować do pliku, ani przefiltrować… oglądać jedynie można. Troszkę to przypomina pisanie palcem po wodzie. Przypominam: to tylko jeśli koniecznie chcecie wymalować tęczę na ekranie się przydaje. W każdym innym wypadku, korzystajcie albo z innych cmdletów Write (jeśli chcecie coś przekazać, bez zaśmiecania wyjścia funkcji), albo w inny sposób utrwalcie. Raport powinien być strumieniem obiektów, który Wasz użytkownik odpowiednio przetworzy: czy to do CSV, czy do GridView, czy do HTML. I tu kolejny zarzut: używanie Format-*. Jeśli funkcja ma w nazwie Get-* (a taką w tej konkurencji należało stworzyć) to formatowaniem nie powinna się zajmować. Jeśli zależy Wam na formacie, stwórzcie go sami przy pomocy plików ps1xml.

Druga istotna wpadka to wsparcie dla rurki… Pamiętajcie: bez bloku process {} tylko się oszukujecie! Taka funkcja ma w sobie tylko blok “end”, czyli przetworzy tylko ostatni wpadający do rurki obiekt. Takie wsparcie, to żadne wsparcie. Inna sprawa to wprowadzanie użytkownika w błąd, że wspieracie wszystko z rurki. Nie da się dobrze obsłużyć dwóch parametrów przyjmujących wartość z rurki ByValue, jeśli oba są typu [string] lub [string[]]. W zasadzie: to jaki by to nie był typ, to pewnie lepiej skupić się w tej sytuacji na jednym. Drugi może sobie brać wartości ByPropretyName – to zwykle działa bez zarzutu.

Dalej: budowanie tablic. Za co? Za jakie grzechy? Po co?

Po pierwsze: dodając element do tablicy wykonujecie cztery operacje: tworzycie nową tablicę o jeden większą niż stara, przepisujecie starą do nowej, dodajecie “nowy” element na końcu, pozbywacie się starocia. Może wygląda to inaczej, ale w praktyce – tak właśnie działa. Więc jeśli koniecznie coś musicie do tablicy intensywnie dodawać, to użyjcie takiej tablicy, która to wspiera (moja ulubiona to [Collections.ArrayList]).

Po drugie: jeśli nie planujecie z tak utworzoną kolekcją absolutnie nic robić – po prostu pomińcie “kolekcjonowanie”. To nie znaczki, puszki, czy motyle. Miejsce obiektu jest w rurce, trzeba go do niej wrzucić najszybciej jak się da!

Kolejna rzecz, która sprawiała, że mi witki opadały: przeliczanie na piechotę wszystkich mega- i gigabajtów. Po co bawić się w mnożenie 1024, skoro PowerShell rozumie zarówno 1gb jak i 1mb? Jak dzielicie przez gigabajty, to po prostu piszcie $zmienna / 1gb. Wystarczy!

Co prawie wyszło?

Tu chciałbym po krótce wspomnieć o dwóch sprawach: użycie atrybutu OutputType i nowej składni dla PSCustomObject.

O tym drugim już wspominałem. Tu dopiszę w jakich sytuacja nie zadziałało to do końca tak, jak powinno. Trzeba Wam wiedzieć, że jest to konstrukcja specjalna. Jeśli stworzycie tablicę skrótów “na boku” i spróbujecie “zrzucić” ją na PSCustomObject, to efekt będzie inny niż zamierzony. Warto o tym pamiętać by nie dziwić się później, że “miało być tak pięknie, po kolei, a jest jak zawsze – chaotycznie”.

O co chodzi z OutputType? Atrybut ten pozwala nam przedstawić naszą funkcję innym zanim ją jeszcze uruchomią. A nawet (w przypadku PowerShella 3) – zanim ją zdefiniują. Ale ważne jest, by przedstawiając nie próbować nikomu wmówić, że dajemy na wyjściu coś innego, niż istotnie z naszej funkcji wychodzi. Ktoś nam uwierzy i na wyjściu Get-Inventory, będzie się spodziewał stringa. A tu psikus, wyskoczy na niego nasz własny obiekt, bez właściwości Length.

I to tyle – zachęcam do udziału w trzeciej konkurencji. Myślę, że mimo wszystko warto spróbować swoich sił. Sam jestem ciekaw, jakie zadanie czeka na nas w trzeciej odsłonie…

~ - autor: Bartek Bielawski w dniu 9 Maj, 2013.

Napisane w PowerShell
Tagi: najlepsze praktyki, OutputType, początki PowerShell, Scripting Games 2013