PowerShell – efektywnie(j), część 2.
W części pierwszej tego cyklu opisałem ogólnie to, jak moim zdaniem praca w PowerShellu różni się w zależności od naszej aktualnej aktywności. Skupiłem się na różnicach między trybem pracy interaktywnej i trybem tworzenia skryptów. Dziś, zgodnie z obietnicą, poznęcam się nieco nad pracą w konsoli.
Badacz
PowerShell daje nam możliwości, których próżno szukać w VBS. Trudno je też znaleźć w cmd, choć temu ostatniemu nieco bliżej do interaktywnej natury PowerShella. W VBS byliśmy skazani na pisanie od zera, sklejanie skryptów z klocków, żmudne testy bez prostej możliwości wglądu w działanie skryptu. PowerShell pozwala każdy obiekt zbadać, obejrzeć, obrócić, przeskanować, rozłożyć na czynniki pierwsze. Nie korzystając z tych możliwości ograniczamy sobie pole działania. Wielu rzeczy o PowerShellu dowiadywałem się po prostu klepiąc TABem na różnych obiektach. Get-Member też zwykle służy pomocą. To wszystko sprawia, że PowerShell jest wręcz stworzony do zgłębiania świata .NET. Swoją drogą to dumam, czy programistom zdarza się uruchamiać PowerShella tylko po to, by sobie szybciutko pogmerać w jakimś skompilowany kodzie…
Oprócz tego możemy pracując obserwować cały czas rezultaty i nasze zachowanie dostosowywać do wyników. Jeśli jakaś metoda wyrzuca błąd – możemy sprawdzić jej definicję, zmodyfikować, uruchomić ponownie… aż do skutku.
Z pewną taką nieśmiałością…
Pisałem już o tym chyba kiedyś, ale ta cecha PowerShella niezmiennie mnie zachwyca. Pięknie o tym mówi w czasie swoich prezentacji o PowerShellu Jeffrey Snover. Spróbuję przetłumaczyć 😉 Odwieczny dylemat administratora:
Czy ta komenda jest poprawna? Czy jeśli ją wykonam, to stracę pracę? Czy przez moją pomyłkę Buffy i Puffy nie pójdą na studia? Może lepiej sprawdzą Co Jeśli…
-WhatIf i –Confirm – dwa parametry, które pewnie nie raz uratują adminowi jego cztery litery, lub przynajmniej pozwolą uniknąć 16-godzinnej dniówki. Korzystać z nich można, należy. Co więcej – korzystanie z –Confirm można w prosty (stosunkowo) sposób wymusić: wystarczy ustawić $ConfirmPreference na odpowiednio niską wartość. Domyślnie jest High (czyli tylko komendy z ConfirmImpact równym High będą wymuszać potwierdzenie). Ustawienie tego parametru na ‘Low’ może sprawić, że PowerShell będzie nas pytał o niemal wszystko. 😉 WhatIf też można wymusić ($WhatIfPrerence = 1) ale to chyba już przesada… Zamiast coś robić, będziemy tylko dostawać informację co by było gdyby… Za to raczej nam nikt nie zapłaci. 😉 A odwrócić to można tylko używając składni:
Komenda –WhatIf:$false
Niezbyt przyjazne, jeśli mam być szczery…
Klocki lego
Pisanie pełnej, “wypasionej” komendy od zera to troszkę jak malowanie obrazu bez szkiców… PowerShell to idealny szkicownik: możemy wykonać jakąś “rurkę”, sprawdzić czy rezultat nas zadowala, dodać kolejną komendę do potoku, sprawdzić. Zapisać w zmiennej, sprawdzić zawartość, przepuścić ją przez foreach ()… I tak, krok po kroku, dojść od koncepcji do pełnego rozwiązania. Czasem oczywiście nie jest to konieczne: łatwiej nam będzie zmodyfikować coś, co już kiedyś w pocie czoła stworzyliśmy. Ale na początku lepiej właśnie posłużyć się techniką “małych kroczków”. PowerShell, przez swoją interaktywność oraz fakt, że składnia w skrypcie niczym się nie różni od tej pisanej w konsoli, daje nam taką możliwość. Warto z niej skorzystać by nie napracować się nad jakimś skryptem tylko po to, by na koniec odkryć, że obiekt który zapowiadał się obiecująco kompletnie nie nadaje się do rozwiązania postawionego przed nami problemu. Budując rozwiązanie stopniowo unikniemy takich frustrujących i zniechęcających przygód.
Krótkie podsumowanie
Na dziś kończę. W następnej części skupię się na “trikach”, które często w konsoli wykorzystuję. Większość z nich opisałem w moim gościnnym artykule na blogu Hey, Scripting Guy! Część jednak dość lakonicznie, tu postaram się nieco bardziej rozpisać… 😉
PowerShell po polsku 