Zmienna działająca tylko w PowerShell wskazuje na inny sposób deklaracji zmiennych ($env:) niekompatybilny ze składnią CMD.
Składnia zmiennej środowiskowej w PowerShell
Określenie „zmienna działa tylko w PowerShell” odnosi się zwykle do zapisu $env:NAZWA. Jest to składnia używana przez PowerShell do odczytywania wartości zmiennych środowiskowych dostępnych dla bieżącego procesu. Przykładowo polecenie $env:Path zwraca zawartość zmiennej Path, a $env:TEMP odczytuje ścieżkę katalogu plików tymczasowych. Dwukropek po $env nie jest elementem nazwy zmiennej, lecz częścią specjalnego mechanizmu dostępu do środowiska procesu.
Nie oznacza to, że sama zmienna środowiskowa istnieje wyłącznie w PowerShell. Zmienne środowiskowe są przechowywane jako dane środowiska procesu systemu Windows i mogą być używane przez różne programy. Tylko sposób odwołania się do nich zależy od powłoki. PowerShell rozpoznaje konstrukcję $env:NAZWA, natomiast CMD używa między innymi zapisu %NAZWA%. W zwykłym skrypcie PowerShell odwołanie %NAZWA% nie pełni tej samej funkcji, ponieważ znak procenta ma w tej powłoce inne znaczenie.
Różnica między PowerShell a wierszem poleceń CMD
W CMD odczyt zmiennej środowiskowej wygląda na przykład tak: echo %TEMP%. W PowerShell odpowiednikiem jest Write-Output $env:TEMP albo samo wpisanie $env:TEMP w interaktywnej sesji. Polecenia należy interpretować zgodnie z powłoką, w której są wykonywane. Wklejenie fragmentu przeznaczonego dla CMD do PowerShell może zwrócić tekst w nieoczekiwanej postaci, pustą wartość albo doprowadzić do błędu składni.
Różnica jest istotna także w plikach skryptowych. Plik .ps1 jest interpretowany przez PowerShell, dlatego odwołanie do zmiennej środowiskowej powinno mieć postać $env:NAZWA. Skrypt wsadowy .bat lub .cmd korzysta z reguł CMD, więc stosuje zapis z procentami. Nie należy mechanicznie zamieniać jednego zapisu na drugi bez sprawdzenia kontekstu. Dotyczy to również argumentów przekazywanych do programów, ścieżek, ustawień narzędzi programistycznych oraz poleceń uruchamianych z automatyzacji.
Zakres zmiany wartości i dziedziczenie procesu
W PowerShell wartość można zmienić dla bieżącej sesji poleceniem $env:APP_MODE = "test". Taka operacja modyfikuje środowisko procesu PowerShell. Program uruchomiony później z tej sesji może odziedziczyć ustawioną wartość, ponieważ proces potomny otrzymuje kopię środowiska procesu macierzystego podczas uruchamiania. Zmiana nie oznacza jednak automatycznej modyfikacji konfiguracji wszystkich już działających programów ani innych otwartych sesji terminala.
Usunięcie zmiennej z bieżącego środowiska można wykonać przez przypisanie wartości $null, na przykład $env:APP_MODE = $null. Należy odróżnić to od trwałego ustawienia zmiennej w konfiguracji systemu lub profilu użytkownika. Zmienna ustawiona tylko w sesji PowerShell może zniknąć po jej zamknięciu. Jeżeli program jest uruchamiany z innego terminala, przez skrót, usługę albo środowisko programistyczne, może otrzymać inny zestaw zmiennych. Przy diagnozowaniu problemu trzeba więc sprawdzić zarówno nazwę zmiennej, jej wartość, jak i sposób uruchomienia procesu.
Rozpoznawanie błędów w skryptach i konfiguracji
Typowym problemem jest użycie poprawnej składni w niewłaściwej powłoce. W PowerShell polecenie echo $env:APP_MODE może odczytać wartość, natomiast w CMD ten zapis nie zostanie zinterpretowany jako odwołanie do zmiennej środowiskowej. Odwrotnie, echo %APP_MODE% jest naturalne dla CMD, lecz nie jest odpowiednikiem składni PowerShell. Warto też uważać na wielkość liter w nazwach zmiennych, cudzysłowy i spacje w wartościach, ponieważ program uruchamiany z terminala może otrzymać inną wartość niż oczekiwana przez skrypt.
Warszawskie Pogotowie Komputerowe wykonuje profesjonalną naprawę laptopów i komputerów PC, w tym diagnostykę problemów z uruchamianiem programów, konfiguracją systemu oraz działaniem skryptów PowerShell w środowisku użytkownika. Podczas sprawdzania takiego przypadku analizuje się używaną powłokę, treść polecenia, dostępność zmiennej w bieżącym procesie i zachowanie programu potomnego. Pozwala to rozdzielić błąd składni od sytuacji, w której zmienna została ustawiona w innej sesji lub nie została przekazana do uruchamianego procesu.
