Git Bash nie widzi zmiennych z Windows

Git Bash nie widzi zmiennych z Windows wskazuje, że zmienne środowiskowe ustawione po otwarciu terminala nie są automatycznie odświeżane — wymaga otwarcia nowej sesji Git Bash.

Git Bash nie widzi zmiennych z Windows — co oznacza ten problem

Komunikat lub zachowanie opisane jako „Git Bash nie widzi zmiennych z Windows” oznacza, że powłoka uruchomiona w środowisku Git for Windows nie korzysta z oczekiwanej wartości zmiennej środowiskowej albo nie znajduje programu wskazanego w zmiennej PATH. Zmienne środowiskowe przechowują ustawienia dostępne dla procesów uruchamianych w systemie, między innymi lokalizacje katalogów z narzędziami, preferowany edytor, nazwę użytkownika czy konfigurację używaną przez skrypty. Git Bash odczytuje te informacje w chwili rozpoczynania sesji, dlatego zmiana wykonana później w ustawieniach Windows zwykle nie pojawia się w już otwartym terminalu.

Nie musi to oznaczać uszkodzenia Git Bash ani błędnej instalacji. Często problem wynika z różnicy między procesem, w którym zmieniono ustawienie, a procesem, który uruchomił terminal. Nowe wartości są przekazywane między procesami przy ich tworzeniu, więc otwarta wcześniej sesja zachowuje wcześniejszy zestaw danych. Z tego powodu polecenie echo $PATH może pokazywać inną zawartość niż ustawienia sprawdzane w panelu systemowym Windows.

Jak Git Bash korzysta ze zmiennych środowiskowych Windows

Git Bash działa jako powłoka uniksowa uruchamiana w środowisku Windows. Udostępnia polecenia i składnię znaną z systemów uniksowych, ale nadal korzysta z mechanizmów systemu Windows, w tym z jego zmiennych środowiskowych. Zmienna PATH jest następnie prezentowana w formie zrozumiałej dla powłoki Bash. Ścieżki mogą być wyświetlane z użyciem ukośników, a katalogi systemowe oraz katalogi instalacyjne programów mogą występować w kolejności odmiennej od tej widocznej w klasycznym wierszu polecenia.

Warto rozróżnić kilka źródeł konfiguracji. Zmienna może być ustawiona globalnie dla systemu, tylko dla bieżącego użytkownika albo tymczasowo w konkretnej sesji. Dodatkowe wartości mogą być też dopisywane przez pliki startowe powłoki, takie jak ~/.bashrc lub ~/.bash_profile, zależnie od sposobu uruchomienia Git Bash. W praktyce oznacza to, że ta sama nazwa może mieć inną wartość w PowerShellu, w wierszu polecenia i w Git Bash, szczególnie gdy konfiguracja powłoki modyfikuje ją podczas startu.

Podstawowe sprawdzenie można wykonać poleceniami printenv NAZWA_ZMIENNEJ, echo "$NAZWA_ZMIENNEJ" oraz echo "$PATH". Do sprawdzenia, jaki plik wykonywalny jest odnajdywany przez powłokę, służy which nazwa_programu. Warto również porównać wynik z poleceniem where.exe nazwa_programu uruchomionym w środowisku Windows. Takie porównanie pomaga ustalić, czy problem dotyczy braku odświeżenia sesji, innej kolejności katalogów, czy nieprawidłowej ścieżki.

Typowe przyczyny i błędy konfiguracyjne - Git Bash nie widzi zmiennych z Windows

Najczęstszą przyczyną jest zmiana zmiennej środowiskowej po uruchomieniu Git Bash. Zamknięcie bieżącego okna i otwarcie nowego zwykle wystarcza, aby terminal pobrał aktualny zestaw wartości. Jeżeli Git Bash został uruchomiony z wcześniej otwartego programu, skrótu przypiętego do paska zadań albo narzędzia deweloperskiego, pomocne może być zamknięcie także procesu nadrzędnego i ponowne uruchomienie terminala.

Drugim źródłem trudności jest modyfikacja niewłaściwej zmiennej. W Windows znaczenie ma między innymi rozróżnienie między ustawieniami użytkownika a ustawieniami systemowymi. W Git Bash nazwy zmiennych są zwykle zapisywane wielkimi literami, a odwołanie następuje przez poprzedzenie nazwy znakiem dolara, na przykład $JAVA_HOME. Samo wpisanie JAVA_HOME nie odczyta wartości, lecz potraktuje tekst jako polecenie lub argument zależnie od kontekstu.

Problemy mogą powodować także błędne wpisy w PATH. Jeżeli dołączony zostanie katalog zawierający plik wykonywalny zamiast pełnej ścieżki do konkretnego programu, jest to zazwyczaj prawidłowe, natomiast dodanie samego pliku lub nieistniejącego katalogu nie przyniesie oczekiwanego rezultatu. Należy uważać na przypadkowe nadpisanie całej zmiennej zamiast dopisania jednego elementu. W Bashu tymczasowe rozszerzenie ścieżki może wyglądać tak: export PATH="$PATH:/ścieżka/do/katalogu". Taka zmiana obowiązuje jednak wyłącznie w aktualnej sesji, chyba że zostanie zapisana w odpowiednim pliku konfiguracyjnym.

Na wynik wpływają również cudzysłowy, spacje oraz sposób zapisu ścieżki. Niewłaściwe połączenie składni Windows i Bash może sprawić, że fragment zawierający spację zostanie potraktowany jako kilka osobnych argumentów. Nie należy też bez sprawdzenia kopiować wartości z jednego terminala do drugiego. Warto najpierw ustalić, czy program rzeczywiście istnieje pod wskazaną lokalizacją, a następnie zweryfikować rezultat w nowej sesji.

Kiedy warto oddać urządzenie do diagnozy - Git Bash nie widzi zmiennych z Windows

Jeżeli po ponownym uruchomieniu Git Bash zmienna nadal ma nieprawidłową wartość, program nie jest odnajdywany mimo poprawnej instalacji albo różne terminale pokazują sprzeczne wyniki, potrzebna może być uporządkowana analiza konfiguracji. Weryfikacji wymaga wtedy nie tylko sama zmienna, lecz także sposób uruchamiania powłoki, pliki startowe, wpisy użytkownika i systemu oraz kolejność katalogów w PATH. Szczególnej ostrożności wymaga usuwanie wpisów, ponieważ nieprzemyślana korekta może utrudnić uruchamianie innych narzędzi.

Do serwisu komputerowego Warszawskie Pogotowie Komputerowe 24/7 można zgłosić problem, gdy potrzebne jest sprawdzenie konfiguracji laptopa, komputera stacjonarnego lub środowiska używanego do pracy programistycznej. W przypadku laptopa przewidziana jest darmowa diagnoza LAPTOPA, co pozwala najpierw ustalić, czy przyczyną jest wyłącznie sesja Git Bash, konfiguracja Windows, czy szerszy problem z instalacją narzędzi. Przed przekazaniem sprzętu warto przygotować nazwę programu, polecenie, które nie działa, wynik echo "$PATH" oraz informację o tym, kiedy zmieniono ustawienia.

Nie zaleca się usuwania całej zawartości zmiennej PATH, instalowania kolejnych wersji narzędzi bez ustalenia przyczyny ani dopisywania przypadkowych katalogów znalezionych w internecie. Najbezpieczniej zachować dotychczasową konfigurację, wykonać kopię istotnych ustawień i wprowadzać pojedyncze zmiany, każdorazowo sprawdzając wynik w nowo otwartej sesji Git Bash.