Windows & Git Bash: Bash PATH для чтения системной переменной Windows% PATH%
45946
Ahmed Fasih
Недавно я добавил каталог в Windows PATH вручную, перейдя в Панель управления -> Система -> Дополнительные параметры системы -> Переменные среды -> Пользовательские переменные -> PATH. (Windows 7, 64-разрядная.)
После перезагрузки и запуска cmd.exe echo %PATH%указывает, что это работает: я вижу каталог, который я недавно добавил в вывод.
Однако после запуска Git Bash выходные данные echo $PATHне включают этот каталог.
Я мог бы добавить export PATH=$PATH:/c/my/pathсвой bashrc, но я бы предпочел, чтобы Git Bash просто получал PATH из Windows, поэтому мне не нужно добавлять пути в двух местах. Как это можно сделать?
(Более общий вопрос заключается в том, что настраивает в Git Bash $ PATH? Я вижу пару записей, повторяющихся в разных местах, некоторые вещи в Windows% PATH% находятся в GAT Bash в $ PATH, но не другие. Что все происходит раньше? Я получаю приглашение Git Bash, которое касается $ PATH?)
Рассматриваемый путь может быть важным: `C: \ cygwin \ usr \ x86_64-w64-mingw32 \ sys-root \ mingw \ bin`.
Ahmed Fasih 11 лет назад
0
Сессия git bash просто добавит перед вашим текущим PATH:
.:/usr/local/bin:/mingw/bin:/bin:
Вполне возможно, что сеанс mingw, упакованный с msysgit, не будет рассматриваться binиз другой установки mingw: вы можете проверить его, установив другой (более простой) каталог в вашем, PATHи посмотреть, виден ли он еще в вашем сеансе git bash. Если нет, то это более общая проблема, которая касается всех каталогов, которые вы бы добавили в PATH.
Это не кажется правильным. Когда я запускаю git bash, его путь задается каким-то процессом, который, по-видимому, преобразует переменную PATH Windows через какой-то процесс. Это не так просто, как добавление дополнительных элементов: ';' переводится в ':', спецификаторы дисков преобразуются в имена каталогов, и некоторые другие преобразования также происходят. В некоторых случаях это преобразование неверно - `" c: \ Program Files \ Java \ jdk1.8.0_25 "\ bin` в моем пути к Windows преобразуется в` / c / Program Files / Java / jdk1.8.0_25 "/ bi` в пути git bash (обратите внимание, пропущены первый и последний символы) ... поэтому вопрос в том, как это происходит?
Jules 6 лет назад
1
@Jules Это действительно возможно. За 5 лет многое изменилось.
VonC 6 лет назад
0
3
anubhav
Вот мой небольшой обход аналогичной проблемы (MSYS2 bash на Windows 10).
Идея состоит в том, чтобы преобразовать необходимые пути в пути в стиле Unix и добавить их в bash $ PATH, все это делается в .bashrc.
Не добавляйте необходимые пути к Win PATH. Вместо этого создайте новую переменную env в Windows, например MSYS2_WINPATH, и добавьте все разделенные точкой с запятой каталоги пути Windows к этой переменной. Добавьте% MSYS2_WINPATH% к% PATH%.
Теперь вставьте это в ваш .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 #################################
Попробовал это в git-bash, и он работал без обходного пути для .bashrc. Спасибо!
Michael Haidl 6 лет назад
0
приятно это слышать :) пожалуйста.
anubhav 6 лет назад
0
2
Tony OHagan
If the PATH value would be too long after your user's PATH variable has been concatenated onto the environment PATH variable, Windows will silently fail to concatenate the user PATH variable.
This can easily happen after new software is installed and adds something to PATH, thereby breaking existing installed software. Windows fail!
The best fix is to edit one of the PATH variables in the Control Panel and remove entries you don't need. Then open a new CMD window and see if all entries are shown in "echo %PATH%".
1
gilly3
Попробуйте переместить каталог в начало вашей переменной пути. У меня была такая же проблема, как и у вас после установки p4merge. К папке был добавлен каталог Perforce, и файл cmd.exe был найден p4merge, но не git shell (mingw). После безрезультатного поиска я попытался просто отредактировать переменную, чтобы сначала в моем пути появился каталог Perforce. Я запустил git shell и, вуаля, каталог включается в вывод $ echo $pathи $ p4mergeоткрывает p4merge.
Это своего рода неубедительный ответ, так как я не знаю, почему это работает, но если обходной путь помогает кому-то другому, отлично.