WSL nie widzi zmiennych Windows

WSL niewidzący zmiennych Windows wskazuje na różnice ścieżek i środowiska między systemem hosta a wirtualną dystrybucją Linux.

WSL nie widzi zmiennych Windows – czym jest ten problem

Problem opisany jako „WSL nie widzi zmiennych Windows” pojawia się wtedy, gdy polecenie uruchomione w dystrybucji Linux działającej przez Windows Subsystem for Linux nie otrzymuje wartości znanych systemowi Windows. Może chodzić o zmienne takie jak PATH, TEMP, USERPROFILE, APPDATA, HOMEDRIVE, HOMEPATH albo własne wpisy dodane w ustawieniach systemowych. Sam fakt, że dana zmienna jest widoczna w PowerShellu lub w wierszu polecenia, nie oznacza jeszcze, że będzie dostępna w powłoce Bash wewnątrz WSL.

WSL tworzy osobne środowisko uruchomieniowe. Dystrybucja Linux ma własny katalog główny, własne pliki konfiguracyjne, własnego użytkownika, odmienny sposób zapisu ścieżek i osobny mechanizm inicjalizacji powłoki. Windows może przekazywać część swoich zmiennych do procesu WSL, ale zakres tego przekazywania zależy od konfiguracji. Znaczenie mają między innymi ustawienia interop, sposób uruchomienia dystrybucji, rodzaj użytej powłoki oraz konfiguracja plików profilu.

W praktyce komunikat lub objaw może wyglądać różnie. Polecenie echo $PATH może nie zawierać katalogów z programami Windows, cmd.exe może działać po wpisaniu pełnej ścieżki, a skrót zapisany w zmiennej własnej może być całkowicie nieznany dla Bash. Czasem problem dotyczy tylko jednego terminala, a czasem każdej nowo otwieranej sesji. Ważne jest odróżnienie braku zmiennej od błędnej wartości zmiennej, niedostępności programu oraz nieprawidłowego tłumaczenia ścieżki.

WSL nie widzi zmiennych Windows – różnice środowisk i ścieżek

Windows i Linux inaczej opisują lokalizację plików. W Windows spotyka się zapis w rodzaju C:\Users\Uzytkownik\Projekt, natomiast w WSL ten sam zasób jest zwykle dostępny jako /mnt/c/Users/Uzytkownik/Projekt. Znak odwrotnego ukośnika ma w Bash inne znaczenie niż w poleceniach Windows, a dwukropek używany w windowsowej zmiennej PATH nie pełni takiej samej roli jak dwukropek w środowisku Linux. Linux rozdziela elementy PATH dwukropkiem, dlatego bezpośrednie skopiowanie zapisu z Windows może prowadzić do nieprawidłowych wpisów.

Warto także rozróżnić trzy sytuacje. Pierwsza to zmienna zdefiniowana wyłącznie w Windows, której WSL nie importuje. Druga to zmienna przekazana do WSL, ale zawierająca ścieżkę zrozumiałą tylko dla aplikacji windowsowej. Trzecia to zmienna istniejąca w Bash, lecz nadpisana w pliku ~/.bashrc, ~/.profile albo w konfiguracji innej powłoki. W każdym przypadku rezultat polecenia może wyglądać podobnie, choć przyczyna wymaga innego działania.

Nie należy zakładać, że WSL jest jedynie oknem do tego samego środowiska. Program uruchomiony w Linuxie korzysta z linuxowych bibliotek i reguł powłoki, a program uruchomiony przez cmd.exe lub PowerShell odczytuje zmienne z kontekstu Windows. Możliwe jest wywołanie aplikacji Windows z WSL, jednak wtedy trzeba uwzględnić sposób przekazania argumentów, konwersję ścieżek i dziedziczenie środowiska. Szczególnej uwagi wymagają narzędzia programistyczne, menedżery pakietów oraz skrypty, które zakładają obecność konkretnej wartości PATH.

WSL nie widzi zmiennych Windows – typowe przyczyny i objawy

Jedną z częstszych przyczyn jest zmiana zmiennej w ustawieniach Windows bez ponownego uruchomienia terminala. Proces, który już działał, zachowuje wcześniejsze środowisko. Zamknięcie pojedynczej karty terminala nie zawsze wystarcza, jeżeli sesja WSL pozostaje aktywna w tle. Pomocne może być zakończenie dystrybucji poleceniem wsl --shutdown uruchomionym po stronie Windows, a następnie ponowne otwarcie WSL. Takie działanie kończy bieżące sesje, więc przed wykonaniem należy zapisać pliki i zamknąć procesy działające w dystrybucji.

Innym powodem może być ustawienie importowania zmiennych w konfiguracji WSL. W pliku /etc/wsl.conf można kontrolować zachowanie integracji z Windows, w tym przekazywanie zmiennych środowiskowych oraz dostęp do poleceń windowsowych. Błąd składni, niewłaściwa nazwa sekcji albo konfiguracja zapisana w innym pliku niż oczekiwany może sprawić, że zmiana nie zostanie zastosowana. Po edycji takiego pliku dystrybucję trzeba zatrzymać i uruchomić ponownie, ponieważ część ustawień jest odczytywana podczas startu.

Objaw może również wynikać z używania innej powłoki niż Bash. Zsh, fish oraz powłoki uruchamiane przez narzędzia programistyczne mogą mieć własne pliki inicjalizacyjne i własną kolejność odczytu ustawień. Zmienna wpisana do ~/.bashrc nie musi pojawić się w sesji uruchomionej przez skrypt, zadanie edytora kodu lub usługę pomocniczą. Trzeba ustalić, jaki proces faktycznie wykonuje polecenie i jaki użytkownik je uruchamia.

Występują także konflikty nazw. Windows może używać nazwy zmiennej, która w narzędziu linuxowym ma inne znaczenie. Problemem bywa ponadto wielkość liter, ponieważ w środowisku Linux nazwy Path, PATH i path mogą być traktowane jako różne. Jeżeli w jednym miejscu zapisano JAVA_HOME, a w innym Java_Home, program może uznać, że wymagana wartość nie istnieje. Podobnie wygląda sytuacja z literówką w nazwie zmiennej albo ze spacją pozostawioną na końcu wartości.

WSL nie widzi zmiennych Windows – praktyczna diagnostyka

Diagnostykę najlepiej rozpocząć od ustalenia, gdzie zmienna istnieje. W PowerShellu można użyć polecenia $env:NAZWA, w wierszu polecenia Windows polecenia echo %NAZWA%, a w WSL polecenia printenv NAZWA lub echo "$NAZWA". Wyniki należy porównać w tej samej sesji użytkownika. Jeżeli PowerShell pokazuje wartość, ale printenv jej nie pokazuje, problem dotyczy przekazania środowiska. Jeżeli obie strony pokazują wartość, a program nadal jej nie używa, przyczyny trzeba szukać w skrypcie, uprawnieniach lub sposobie startu programu.

Przy analizie PATH warto wyświetlić każdy wpis w osobnym wierszu. W WSL można użyć polecenia printf '%s\n' "$PATH" | tr ':' '\n'. Pozwala to sprawdzić, czy występują puste elementy, ścieżki z niepoprawnymi separatorami, katalogi nieistniejące w danej dystrybucji albo wpisy wskazujące na niewłaściwą wersję programu. Warto potwierdzić, jaki plik wykonywalny jest wybierany, używając command -v nazwa_programu oraz, zależnie od sytuacji, type -a nazwa_programu.

Jeżeli celem jest użycie programu Windows, należy sprawdzić, czy interop działa prawidłowo. Proste polecenie, na przykład cmd.exe /c echo %USERNAME%, może pokazać, czy WSL potrafi uruchomić proces Windows. Nie powinno się jednak mieszać bezpośrednio składni zmiennych obu powłok. W Bash odwołanie ma postać $NAZWA, w PowerShellu $env:NAZWA, a w cmd.exe %NAZWA%. Skrypt korzystający z niewłaściwej składni może sprawiać wrażenie, że zmienna zniknęła.

Przydatne jest wykonanie testu w czystej sesji, bez dodatkowych rozszerzeń terminala i bez automatycznego uruchamiania projektu. Można porównać wynik z sesją po odczytaniu pliku profilu oraz sprawdzić, czy problem pojawia się również dla nowego użytkownika WSL. Jeżeli nowy użytkownik otrzymuje poprawne środowisko, przyczyny należy szukać w plikach konfiguracyjnych konkretnego konta. Jeżeli problem dotyczy całej dystrybucji, należy przejrzeć ustawienia WSL i integracji z Windows.

WSL nie widzi zmiennych Windows – bezpieczne rozwiązania i moment zgłoszenia

Najprostszym rozwiązaniem jest świadome ustawienie zmiennej w odpowiednim środowisku zamiast zakładania, że zostanie automatycznie odziedziczona. Zmienne potrzebne tylko aplikacjom Linux można zapisać w konfiguracji powłoki Linux, a wartości przeznaczone dla programów Windows pozostawić w ustawieniach Windows. Przy ścieżkach należy stosować format właściwy dla programu, który będzie z nich korzystał. Nie każda ścieżka Windows wymaga konwersji do formatu Linux i nie każdą ścieżkę linuxową zrozumie aplikacja uruchomiona po stronie Windows.

Przed zmianą plików profilu warto wykonać kopię ich treści albo dopisać komentarz opisujący cel wpisu. Należy unikać wielokrotnego dopisywania tego samego katalogu do PATH przy każdym uruchomieniu powłoki, ponieważ po kilku sesjach zmienna może stać się długa i trudna do sprawdzenia. Wpisy powinny być jednoznaczne, ograniczone do potrzebnych katalogów i umieszczone w pliku odpowiadającym używanej powłoce. Po modyfikacji trzeba otworzyć nową sesję i ponownie sprawdzić wynik.

Zgłoszenie do serwisu ma sens, gdy zmienne znikają po restarcie, konfiguracja działa tylko dla jednego konta, polecenia Windows są niedostępne z WSL, a także wtedy, gdy problem pojawia się po aktualizacji Windows, zmianie dystrybucji lub instalacji narzędzi programistycznych. Przydatne będzie przekazanie informacji o wersji Windows, nazwie dystrybucji, używanej powłoce, przykładowej zmiennej oraz dokładnym komunikacie błędu. Nie powinno się przesyłać haseł, kluczy dostępowych ani pełnych wartości zmiennych zawierających dane poufne.

W Warszawskim Pogotowiu Komputerowym 24/7 można zgłosić problem z konfiguracją środowiska Windows i WSL, gdy samodzielne porównanie sesji nie wskazuje przyczyny albo zmiana jednego ustawienia powoduje kolejne błędy. Naprawy z reguły realizowane są do 3 dni roboczych. Przed przekazaniem urządzenia warto opisać, czy problem dotyczy wszystkich dystrybucji, tylko jednej powłoki, czy wyłącznie konkretnego programu. Tak przygotowany opis skraca drogę do rozpoznania, czy źródłem jest konfiguracja WSL, profil użytkownika, ścieżka PATH, interop czy aplikacja uruchamiana w nieodpowiednim środowisku.