Windows & Git Bash: Bash PATH для чтения системной переменной Windows% PATH%

Question

Недавно я добавил каталог в 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, поэтому мне не нужно добавлять пути в два места. Как это можно сделать?

(Более общий связанный с этим вопрос: что настраивает GAT Bash для $ PATH? Я вижу несколько записей, повторяющихся в разных местах, некоторые вещи в Windows% PATH% находятся в GAT Bash в $ PATH, но не другие. Что все происходит перед тем, как я получаю приглашение Git Bash, которое касается $ PATH?)

Answer 1

В сеансе msysgit git bash используется сценарий share/WinGit/Git Bash.vbs, который не обращается к переменной окружения PATH и не изменяет ее (как, например, в этом несвязанном сценарии vbs)

Сессия git bash просто добавит перед вашей текущей PATH:

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

Возможно, что сеанс mingw, упакованный с msysgit, не будет рассматривать bin из другой установки mingw: вы можете проверить его, установив другой (более простой) каталог в PATH и посмотреть, виден ли он еще в вашем сеансе git bash. Если нет, то это более общая проблема, которая касается всех каталогов, которые вы бы добавили в PATH.

Answer 2

Вот мой небольшой обход аналогичной проблемы (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 #################################

Answer 3

Если значение PATH будет слишком длинным после того, как переменная PATH вашего пользователя будет конкатенирована с переменной PATH среды, Windows молча прекратит конкатенацию пользовательской переменной PATH.

Это может легко произойти после установки нового программного обеспечения и добавления чего-либо в PATH, тем самым нарушая существующее установленное программное обеспечение. Windows не работает!

Лучшее решение - отредактировать одну из переменных PATH на панели управления и удалить ненужные записи. Затем откройте новое окно CMD и посмотрите, отображаются ли все записи в «echo% PATH%».

Answer 4

Попробуйте переместить каталог в начало вашей переменной пути. У меня была такая же проблема, как и у вас после установки p4merge. К папке был добавлен каталог Perforce, и файл cmd.exe был найден p4merge, но не git shell (mingw). После безрезультатного поиска я попытался просто отредактировать переменную, чтобы сначала в моем пути появился каталог Perforce. Я запустил git shell и, вуаля, каталог включен в вывод $ echo $path , и $ p4merge открывает p4merge.

Это своего рода неубедительный ответ, так как я не знаю, почему это работает, но если обходной путь помогает кому-то другому, отлично.