Windows i Git Bash: Bash PATH, aby odczytać zmienną systemową Windows% PATH%

Niedawno ręcznie dodałem katalog do ŚCIEŻKI systemu Windows, przechodząc do Panelu sterowania -> System -> Zaawansowane ustawienia systemu -> Zmienne środowiskowe -> Zmienne użytkownika -> ŚCIEŻKA. (Windows 7, 64-bitowy).

Po ponownym uruchomieniu i uruchomieniu cmd.exe echo %PATH%wskazuje, że to zadziałało: widzę katalog, który ostatnio dodałem w danych wyjściowych.

Jednak po uruchomieniu Git Bash dane wyjściowe echo $PATHnie zawierają tego katalogu.

Mógłbym dodać export PATH=$PATH:/c/my/pathmój bashrc, ale wolałbym, aby Git Bash po prostu pobierał PATH z Windows, więc nie muszę pamiętać, aby dodawać ścieżki do dwóch miejsc. Jak można tego dokonać?

(Bardziej ogólne pytanie dotyczy tego, co konfiguruje $ PATH Git Bash? Widzę kilka wpisów powtarzanych w różnych miejscach, niektóre rzeczy w Windows% PATH% znajdują się w $ PATH Git Bash, ale nie inne. Co się dzieje wcześniej Dostaję monit Git Bash, który dotyka $ PATH?)

Sesja msitgit git bash korzysta ze skryptu share/WinGit/Git Bash.vbs, który nie uzyskuje dostępu do zmiennej środowiskowej ani jej nie modyfikuje PATH(na przykład w niepowiązanym skrypcie VBS )

Sesja git bash po prostu doda przed bieżącą PATH:

.:/usr/local/bin:/mingw/bin:/bin:

Możliwe, że sesja mingw spakowana z msysgit nie rozważy bininnej instalacji mingw: możesz to sprawdzić, ustawiając inny (prostszy) katalog dla siebie PATHi sprawdzając, czy nadal jest widoczny w twojej sesji git bash. Jeśli nie, to jest to bardziej ogólny problem, który dotyczy wszystkich katalogów dodanych do ŚCIEŻKI.

Oto moje małe obejście podobnego problemu (MSYS2 bash na Windows 10).

Chodzi o to, aby przekonwertować wymagane ścieżki na ścieżki w stylu uniksowym i dołączyć je do bash $ PATH, wszystko wykonane w .bashrc.

Nie dołączaj wymaganych ścieżek do ścieżki PATH. Zamiast tego utwórz nową zmienną env w systemie Windows, na przykład MSYS2_WINPATH, i dołącz do tej zmiennej wszystkie katalogi ścieżek systemu Windows oddzielone średnikami. Dołącz% MSYS2_WINPATH% do% PATH%.

Teraz wstaw to do swojego .bashrc -

################################## Construct PATH variable ##################################

winpath=$(echo $MSYS2_WINPATH | tr ";" "\n" | sed -e 's/\\/\\\\/g' | xargs -I {} cygpath -u {})
unixpath=''

# Set delimiter to new line
IFS=$'\n'

for pth in $winpath; do unixpath+=$(echo $pth)":"; done

export PATH=$(echo $PATH:$unixpath | sed -e 's/:$//g')
unset IFS
unset unixpath
unset winpath

################################# Constructed PATH variable #################################

Jeśli wartość PATH byłaby zbyt długa po skonkatenowaniu zmiennej PATH użytkownika ze zmienną PATH środowiska, system Windows po cichu nie będzie mógł konkatenować zmiennej PATH użytkownika.

Może się to łatwo zdarzyć po zainstalowaniu nowego oprogramowania i dodaniu czegoś do ŚCIEŻKI, co spowoduje uszkodzenie istniejącego zainstalowanego oprogramowania. Windows nie działa!

Najlepszym rozwiązaniem jest edycja jednej ze zmiennych PATH w Panelu sterowania i usuwanie niepotrzebnych wpisów. Następnie otwórz nowe okno CMD i sprawdź, czy wszystkie wpisy są wyświetlane w „echo% PATH%”.

Spróbuj przenieść katalog na początek zmiennej ścieżki. Miałem ten sam problem co ty po zainstalowaniu p4merge. Katalog perforce został dodany do ścieżki i p4merge został znaleziony przez cmd.exe, ale nie git shell (mingw). Po bezowocnym wyszukiwaniu próbowałem po prostu edytować zmienną, tak aby katalog perforce pojawił się pierwszy na mojej ścieżce. Uruchomiłem git shell i, voila, katalog jest zawarty w wyjściu $ echo $pathi $ p4mergeotwiera p4merge.

To trochę kiepska odpowiedź, ponieważ nie mam pojęcia, dlaczego to działa, ale jeśli obejście pomaga komuś innemu, to świetnie.