Windows & Git Bash: Bash PATH для зчитування системної змінної Windows% PATH%


27

Нещодавно я додав каталог в 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, так що мені не потрібно пам'ятати, щоб додати шляхи до двох місць. Як це можна досягти?

(Більш загальне пов'язане питання полягає в тому, що встановлює $ PATH Гіта Баша? Я бачу, як кілька записів повторюються в різних місцях, деякі речі, які знаходяться в Windows% PATH%, містяться в $ PATH Git Bash, але не в інших. Що все відбувається раніше Я отримую підказку Git Bash, яка торкається $ PATH?)


Шлях в питанні може бути важливим: C:\cygwin\usr\x86_64-w64-mingw32\sys-root\mingw\bin.
Ахмед Фасіх

Відповіді:


6

Сеанс bash msysgit git використовує скрипт share/WinGit/Git Bash.vbs, який не має доступу та не змінює змінну середовища PATH(як, наприклад, у цьому непов'язаному скрипті vbs )

Сеанс git bash просто додасться перед поточним PATH:

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

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


1
Це не здається правильним. Коли я запускаю git bash, його шлях встановлюється деяким процесом, який, очевидно, перетворює змінну Windows PATH через якийсь процес. Це не так просто, як додавання додаткових елементів: ';' перекладається на ':', специфікатори накопичувача перетворюються на імена каталогів, і деякі інші перетворення також відбуваються. У деяких випадках це перетворення помилкове - "c:\Program Files\Java\jdk1.8.0_25"\binу моєму Windows шлях конвертується /c/Program Files/Java/jdk1.8.0_25"/biу шлях git bash (відмітка першого та останнього символу) ... тому питання полягає в тому, як це відбувається?
Жуль

@Jules Це можливо справді. За 5 років багато що змінилося.
VonC

5

Ось мій невеликий спосіб вирішення подібної проблеми (MSYS2 баш в Windows 10).

Ідея полягає в тому, щоб перетворити необхідні шляхи в контури стилю Unix і додати їх до bash $ PATH, все зроблено в .bashrc.

Не додавати потрібні шляхи до Win PATH. Замість цього створіть нову var en в Windows, як-от MSYS2_WINPATH, і додайте до цієї змінної всі розділені крапкою з комою крапки з комою. Додайте% 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. Спасибі!
Майкл Гайдл

приємно це почути :) ласкаво просимо.
anubhav

2

Якщо значення PATH буде занадто довгим після того, як змінна PATH вашого користувача була об'єднана в змінну PATH середовища, Windows мовчки не зможе з'єднати змінну PATH користувача.

Це може легко статися після встановлення нового програмного забезпечення та додавання чогось у PATH, тим самим порушуючи існуюче встановлене програмне забезпечення. Windows виходить з ладу!

Найкраще виправити - відредагувати одну із змінних PATH на панелі керування та видалити записи, які вам не потрібні. Потім відкрийте нове вікно CMD і подивіться, чи всі записи відображені в "echo% PATH%".


1

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

Це своєрідна кульгава відповідь, оскільки я незрозумілий, чому це працює, але якщо робота допомагає комусь іншому, чудово.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.