Większość automatyzacji, funkcji i skryptów PowerShell opiera się na danych wejściowych. Dane to procesujemy w najróżniejszy sposób – sprawdzamy, oczyszczamy, porównujemy, wzbogacamy, aby na wyjściu podjąć odpowiednie działania.
Najczęstszym sposobem wprowadzania danych do funkcji jest określanie wartości parametrów. Często jednak potrzebujemy danych z różnych źródeł w masowej ilości.
Dlatego poniżej 6 poleceń/skryptów PowerShell do pobierania danych z sześciu różnych lokalizacji.
Windows PowerShell to dojrzały język skryptowy oparty na .Net, którego od początku ogromną zaletą jest obiektowość, ale nie tylko. O tym dlaczego warto poznać PowerShell pisałem chociażby, tutaj – 9 powodów dlaczego warto (dobrze) znać PowerShell
Dlatego nie przedłużając zapraszam, do poznania podstawowych komendy i pojęć związanych z PowerShell, które wg mnie pozwalają na pierwsze kroki w interaktywnej pracy z tym rozwiązaniem.
Wiele poradników, książek, kursów o PowerShell zaczyna od podstawowych cmdletów takich jak Get-Command i Get-Help. Sam również polecam się z nimi zapoznać, jeśli zaczynasz naukę PowerShell.
Mimo że polecenia realizują inne zadania, to mają jedną wspólną rzecz. Dzięki jednemu i drugiemu poznasz składnie interesujących Cię poleceń.
Nowy rok jest zawsze dobrym momentem na nowe wyzwania, postanowienia, nawet jeśli głośno o nich nie mówimy. Jeśli w Twoim celem jest nauka PowerShell lub poszerzenie wiedzy na jego temat to ten post jest dla Ciebie.
Poniżej znajdziesz zebrane zasoby, które pomogą Ci uczyć się PowerShell w 2020 roku.
Dzisiaj zacznę nietypowo. Spójrz na poniższy fragment kodu i odpowiedź na pytane. Czy to zadziała?
Jeśli od razu pomyślałeś, “nie ma mowy” to problem z przeniesieniem zmiennych lokalnych do poleceń zdalnych nie jest Ci obcy. Jeśli jednak miałeś wątpliwości (spoko, sporo osób je ma) to zapraszam Cię do wpisu, w którym wyjaśniam, dlaczego nie mogło to zadziałać.
Wszystkiemu winny jest…
Zakres sesji
Z zakresem sesji trzeba się zmierzyć, nie tylko używając Invoke-Command ale również Start-Job.
Lokalny skrypt jest wykonywany w zakresie innej sesji niż blok skryptu wykonany przez Invoke-Command lubStart-Job. Zdefiniowane zmienne $Path i $Desintation istnieją tylko w naszej (lokalnej) sesji. Natomiast w zdalnej po prostu ich nie ma, więc mają wartość $null.
Wykonaj poniższy przykład aby przekonać się, że to napisałem to prawda.
Działa to tak a nie inaczej, ponieważ PowerShell zakłada, że zmienne używane w zdalnych poleceniach zostaną tam zdefiniowane. Czyli PowerShell domyślnie oczekuje czegoś takiego.
Jest to jakieś rozwiązanie, jednak znacznie częściej będziesz chciał przekazać wartości z lokalnego skryptu (sesji) do sesji zdalnej. Co wtedy?
Zobacz 3 podejścia przeniesienia zmiennych lokalnych do poleceń zdalnych.
1. Zmienna automatyczna $args
Wykorzystaj parametr -ArgumentList polecenia Invoke-Command lub Start-Job do przekazania wartości zmiennych. Wartości te trafią (nie zawsze) do automatycznej zmiennej $args, którą wykorzystasz w bloku skryptu.
Zmienna $args jest tablicą, dlatego pierwszą wartość znajdziesz w $args[0], drugą w $args[1] i tak dalej.
2. Blok parametrów
Wykorzystaj w bloku skryptu, blok parametrów tak jak w skrypcie lub funkcji. Określ niezbędne parametry, których wartość następnie przekażesz podobnie jak wyżej, poprzez -ArgumentList.
Jeśli blok skryptu ma zadeklarowane parametry to zmienna automatyczna $args jest pomijana (stąd te nie zawsze), chyba że argumentów w -ArgumentList będzie więcej niż parametrów w bloku param().
3. Modyfikator zakresu `Using:`
Począwszy od PowerShell 3.0, sprawa uproszczono maksymalnie. Wystarczy skorzystać z modyfikatora zakresu Using:<nazwa zmiennej> aby przenieść zmienną lokalną do zdalnego polecenia.
W tym podejściu -ArgumentList jest kompletnie niepotrzebny. Tylko oznaczamy modyfikatorem w bloku skryptu, które zmienne lokalne zostaną użyte w zdalnej sesji.
Podsumowanie
We wpisie wyjaśniłem, dlaczego występuje problem z przeniesienia zmiennych lokalnych do poleceń zdalnych i jak sobie z nim radzić.
Ostatnia sprawa, jeśli nie musisz zapewniać kompatybilności z PowerShell 2.0 to wykorzystuj w pierwszej kolejności modyfikator sesji Using:.
Dzięki “pionowej kresce” w poleceniach, można wykorzystać pełną moc PowerShell. Znak potoku | bo o nim mowa, umożliwia nam łączyć wiele poleceń w potężne jednowierszowe sekwencję.
W ten sposób osiągamy w jednym wierszu to, co zwykle wymagałoby pisania kilku linii w skrypcie. Wszystko to zasługa potoku.
Potok
Potok zapewnia efektywny sposób przekazywania wyników pomiędzy poleceniami. Każdy znak potoku | powoduję próbę wysyła wyniku poprzedniego polecenia do następnego.
Parafrazując, dane wyjściowe pierwszego polecenia trafiają jako dane wejściowe do następnego polecenia, dane drugiego do kolejnego i tak dalej. Jak woda w potoku, wyniki w PowerShell “płyną” z lewej do prawej.
Jeden niuans, nie wszystkie polecenia akceptują przekazane dane z potoku.
Jak sprawdzić?
Najprościej, sięgając do treści pomocy. W tym celu wykonaj polecenie help z parametrem -Parameter * i zwróć uwagę na Accept pipeline input.
Oprócz informacji, do jakich parametrów możliwe jest przekazanie wartości, również dowiesz się jakiego typu dane oraz jakie metody wiązania są akceptowane.
Metoda ByValue
Metody są dwie, jednak ByValue ma pierwszeństwo. Jej działanie jest proste, polega na przekazaniu całego obiektu (wszystkich właściwości, metod, aliasów) do kolejnego polecenia.
Zobacz na przykładzie. Get-Process zwraca obiekt typu System.Diagnostics.Process. który jest w całości przekazywany do polecenia Stop-Process. Nastąpi to dopiero po tym jak powłoka PowerShell sprawdzi, czy jakikolwiek parametr polecenie akceptuję meotdę ByValue i przyjmuję obiekt takiego typ.
Jeśli wszystkie warunki są spełnione, wykonywane jest polecenie Stop-Process, jeśli nie to powłoka sprawdza drugą metode.
Metoda ByPropertyName
ByValue opiera się na typie obiektu, natomiast ByPropertyName tylko na nazwie właściwości. Oczywiście wcześniej sprawdzając, czy parametr akceptuję dane z potoku.
W przeciwieństwie do ByValue, która akceptuję jedno wiązanie, ta metoda pozwala na wiązanie wielu pasujących do siebie właściwości i parametrów.
W przypadku Get-Item -Path . | Stop-Process typ obiektu nie zgadza się z typem parametru InputObject. Dlatego wystąpiło wiązanie po nazwie właściwości Name i wykonanie polecenia Stop-Process.
Takie polecanie nie ma większego sensu, ale jako przykład jest idealne 🙂
Dla ciekawskich
Jeśli chciałbyś podejrzeć co dokładnie PowerShell wykonuję w momencie użycia znaku potoku z pomocą przychodzi polecenie Trace-Command.
Podsumowanie
Wpis miał przybliżyć jak PowerShell podejmuję decyzję, kiedy wyjście jednego polecenie może zostać przekazane do kolejnego.
Na początku stosowania potoku może być nieintuicyjne, ale przy odrobinie praktyki przekonasz się, że łączenie poleceń oszczędza czas, a także zwiększa efektywność skryptów.
By 
