Skrypty PowerShell nie dziedziczą zmiennych

Skrypty PowerShell niedziedziczące zmiennych wskazują na osobny zakres (scope) wywołania — zmienne globalne wymagają jawnego odwołania $global:.

Skrypty PowerShell nie dziedziczą zmiennych – czym jest ten problem

Określenie „skrypty PowerShell nie dziedziczą zmiennych” opisuje sytuację, w której wartość utworzona w jednym zakresie działania nie jest automatycznie dostępna w innym zakresie. W PowerShell zmienna nie jest wyłącznie nazwą przechowującą tekst, liczbę, obiekt albo wynik polecenia. Ma także przypisany zakres widoczności, czyli miejsce, w którym można się do niej odwołać bez dodatkowych oznaczeń. Zakres wpływa na sposób działania skryptu, funkcji, bloku kodu oraz sesji konsoli.

Najczęściej występuje zakres lokalny i globalny. Zakres lokalny odnosi się do bieżącego miejsca wykonywania kodu. Gdy zmienna zostanie utworzona wewnątrz funkcji, zwykle pozostaje dostępna przede wszystkim w tej funkcji. Po zakończeniu jej działania wartość może nie być widoczna dla kodu znajdującego się na zewnątrz. Zmienna zdefiniowana w głównej części skryptu może natomiast być dostępna dla kodu uruchamianego w tym samym kontekście, ale nie należy zakładać, że zachowa się identycznie w każdym sposobie wywołania.

W praktyce problem wynika często z pomieszania dwóch pojęć: przekazywania danych oraz dziedziczenia zakresu. Funkcja może otrzymać wartość jako parametr, zwrócić ją za pomocą instrukcji return albo odwołać się do zmiennej z innego zakresu przy użyciu kwalifikatora. Sam fakt, że zmienna istnieje w konsoli, nie oznacza jeszcze, że każdy uruchamiany skrypt będzie mógł ją odczytać. Szczególnie istotne jest to przy pracy z osobnymi plikami .ps1, funkcjami i poleceniami wykonywanymi w podzakresach.

Skrypty PowerShell bez dziedziczenia zmiennych – zakresy i porównania

Zakres lokalny można porównać do prywatnego obszaru roboczego funkcji. Zmienna utworzona w takim obszarze służy do wykonania bieżącej operacji i nie powinna być traktowana jako wspólny magazyn dla całego skryptu. Zakres globalny obejmuje bieżącą sesję PowerShell i może zawierać dane przygotowane przed uruchomieniem funkcji albo skryptu. Między tymi zakresami istnieje rozróżnienie, którego nie wolno pomijać przy analizie kodu.

Jeżeli potrzebne jest jawne użycie zmiennej globalnej, stosuje się zapis $global:NazwaZmiennej. Przykładowo:

$global:TrybPracy = "test"

W innym miejscu kodu można odczytać tę wartość za pomocą $global:TrybPracy. Taki zapis wskazuje, że odwołanie ma dotyczyć zakresu globalnego, a nie zmiennej lokalnej o podobnej nazwie. Jest to istotne, ponieważ w funkcji może zostać utworzona zmienna lokalna o tej samej nazwie. Wtedy zapis $TrybPracy może wskazywać inną wartość niż $global:TrybPracy.

Warto rozróżnić także zakres skryptu oraz zakres lokalny funkcji. Skrypt może posiadać własne zmienne, których przeznaczeniem jest obsługa jego wewnętrznego przebiegu. Gdy funkcja zostanie uruchomiona z tego skryptu, sposób dostępu do danych zależy od miejsca deklaracji, rodzaju wywołania i tego, czy wartość została przekazana jawnie. Najbardziej przewidywalny model polega na przekazywaniu danych przez parametry oraz zwracaniu wyników, zamiast na opieraniu logiki na ukrytych zależnościach globalnych.

Podobne rozbieżności mogą pojawić się przy użyciu operatora wywołania &, polecenia Invoke-Expression oraz przy uruchamianiu pliku w osobnym procesie. W każdym przypadku należy sprawdzić, czy kod działa w aktualnej sesji, w podzakresie, czy w nowym procesie. Nowy proces nie korzysta automatycznie z przypadkowych zmiennych utworzonych w procesie nadrzędnym. Jeżeli dane mają zostać przekazane, powinny zostać zapisane w parametrach, argumentach, pliku konfiguracyjnym albo innym jasno opisanym mechanizmie wymiany.

Skrypty PowerShell nie widzą zmiennych – typowe problemy w kodzie

Jednym z częstych błędów jest utworzenie zmiennej w funkcji i próba odczytania jej po zakończeniu funkcji. Kod może wykonać się bez komunikatu o błędzie, ale późniejszy fragment otrzyma wartość pustą albo nieoczekiwaną. Innym przypadkiem jest przypisanie wartości do zmiennej lokalnej zamiast do zmiennej globalnej. W funkcji zapis $Ustawienie = "nowe" nie musi zmienić wcześniej istniejącego $global:Ustawienie. Powstaje wtedy druga zmienna, należąca do innego zakresu.

Problemy pojawiają się także wtedy, gdy nazwa zmiennej jest używana w kilku funkcjach bez jednoznacznego ustalenia jej właściciela. Kod staje się trudniejszy do odczytania, a zmiana kolejności wywołań może zmienić rezultat. Szczególną ostrożność należy zachować przy zmiennych o krótkich nazwach, takich jak $i, $data, $result albo $config. Ich znaczenie może być inne w funkcji, inne w głównym skrypcie, a jeszcze inne w module.

Do diagnozy przydatne są polecenia pozwalające sprawdzić obecność i wartość zmiennej. Można użyć Get-Variable, sprawdzić typ za pomocą .GetType().FullName albo wyświetlić wartość w kontrolowanym miejscu kodu. W razie wątpliwości warto porównać:

$Nazwa
$local:Nazwa
$script:Nazwa
$global:Nazwa

Takie porównanie pomaga ustalić, czy problem dotyczy braku wartości, błędnego zakresu, literówki, nadpisania danych, czy też uruchomienia skryptu w innym procesie. Należy również sprawdzić, czy zmienna nie jest tworzona warunkowo. Jeżeli przypisanie znajduje się wyłącznie w jednej gałęzi instrukcji if, w pozostałych przypadkach zmienna może nie zostać utworzona.

Wątpliwości może powodować również potok. Obiekt przekazywany przez potok nie staje się automatycznie zmienną dostępną w całym skrypcie. Jeżeli wynik ma być wykorzystany później, należy zapisać go jawnie, na przykład w postaci $Wynik = Get-Process. Sama obecność obiektu w potoku nie zapewnia jego dostępności po zakończeniu konkretnego polecenia.

Skrypty PowerShell i zmienne – praktyczne wskazówki

Najbezpieczniejszym rozwiązaniem jest projektowanie funkcji tak, aby wejście i wyjście były widoczne w jej definicji. Parametry powinny opisywać dane wymagane do wykonania operacji, a rezultat powinien być zwracany jako obiekt. Przykładowy schemat może wyglądać następująco:

param(
    [string]$Nazwa
)

$Komunikat = "Przetwarzanie: $Nazwa"
$Komunikat

W tym modelu funkcja nie musi wiedzieć, jakie zmienne istnieją poza nią. Dzięki temu można ją łatwiej testować, przenosić do innego pliku i uruchamiać w różnych warunkach. Jeżeli kilka części skryptu korzysta z tych samych ustawień, można przekazać obiekt konfiguracji jako parametr zamiast tworzyć wiele zależności globalnych.

Zakres $script: bywa użyteczny, gdy dane mają być współdzielone przez elementy jednego pliku skryptu albo modułu. Nie powinien jednak zastępować parametrów w sytuacjach, w których funkcja ma być niezależna. Zakres $global: należy stosować oszczędnie, ponieważ zmiana globalnej wartości może wpływać na późniejsze działania w tej samej sesji. W rozbudowanych skryptach rozsądniej jest ograniczać widoczność danych i jawnie przekazywać zależności.

Przy testowaniu warto uruchamiać skrypt w czystej sesji, aby wcześniejsze wartości nie maskowały błędu. Pomocne jest także rozdzielenie etapów: wczytania konfiguracji, walidacji parametrów, wykonania operacji i prezentacji wyniku. Jeżeli po każdym etapie wiadomo, jakie dane powinny istnieć oraz w jakim zakresie, szybciej można wskazać miejsce utraty wartości.

Dobrą praktyką jest stosowanie pełnych, opisowych nazw, komentarzy przy nietypowych kwalifikatorach oraz jawnych parametrów. Warto też unikać przypisywania do zmiennej globalnej w kilku różnych funkcjach. Gdy jest to konieczne, miejsce modyfikacji powinno być jednoznacznie opisane, a kod powinien sprawdzać, czy dana wartość ma poprawny typ i oczekiwaną zawartość.

Kiedy zgłosić skrypty PowerShell do serwisu

Do serwisu warto zgłosić problem, gdy skrypt działa poprawnie tylko na jednym komputerze, po ponownym uruchomieniu traci ustawienia albo zachowuje się inaczej przy ręcznym i automatycznym wywołaniu. Wskazaniem do sprawdzenia jest również sytuacja, w której polecenia w konsoli widzą zmienną, ale plik .ps1 zgłasza jej brak. Przyczyną może być zakres, sposób uruchomienia, uprawnienia, różnica między wersjami środowiska albo błąd w samym kodzie.

Przed przekazaniem zgłoszenia dobrze przygotować treść komunikatu błędu, fragment odpowiedzialny za utworzenie i odczyt zmiennej oraz informację o tym, jak skrypt jest uruchamiany. Przydatne jest wskazanie, czy problem pojawia się w funkcji, module, zadaniu automatycznym czy w zwykłej konsoli. Nie należy umieszczać w zgłoszeniu haseł, kluczy dostępu ani innych poufnych danych.

Warszawskie Pogotowie Komputerowe 24/7 może pomóc w uporządkowaniu przyczyny problemu ze skryptem, środowiskiem PowerShell lub konfiguracją komputera. W ramach analizy można ustalić, czy zmienna znajduje się w niewłaściwym zakresie, czy została nadpisana, czy też skrypt jest uruchamiany w innym kontekście niż zakładano. Takie rozpoznanie pozwala dobrać rozwiązanie oparte na parametrach, prawidłowym kwalifikatorze zakresu albo zmianie sposobu uruchamiania.

Najważniejsze jest zachowanie jasnego przepływu danych. Zmienna powinna być tworzona tam, gdzie jest potrzebna, przekazywana jawnie do funkcji i zwracana w postaci wyniku, jeżeli ma być użyta dalej. Gdy zastosowanie zakresu globalnego jest uzasadnione, należy oznaczyć je w kodzie i kontrolować miejsca modyfikacji. Dzięki temu skrypty PowerShell stają się łatwiejsze do diagnozowania, przewidywalniejsze po ponownym uruchomieniu i mniej podatne na błędy wynikające z niejawnych zależności.