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

Недавно я добавил каталог в 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?)

В сеансе 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.

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

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

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

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

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

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