Git Bash не видит мой путь

Когда я использую Git Bash (в Windows), я не могу запустить любой исполняемый файл без указания его полного пути, хотя он находится в папке, которая находится в моей переменной PATH. Похоже, Bash не распознает это. Зачем? Могу ли я это исправить?

Ответы на вопрос(15)

env|grep PATH в Bash, чтобы подтвердить, какой путьЭт видит.

когда пытаюсь использовать mingw для компиляции lib xgboost в Win10. Наконец-то я нашел решение.

Создайте файл с именем .bashrc в своем домашнем каталоге (обычно это C: \ Users \ username). Затем добавьте путь к нему. Не забудьте использовать кавычки, если ваш путь содержит пробел, и не забудьте использовать / c / вместо C: /

Например

PATH = $ PATH: "/ c / Program Files / mingw-w64 / x86_64-7.2.0-posix-seh-rt_v5-rev1 / mingw64 / bin"

bin" в корне диска C: 2) Добавить "C: / bin;" в PATH в «Мой компьютер -> Свойства -> Переменные Environemtal»

я привык набирать исполняемые имена без расширений. В моем случае я хотел выполнить файл с именемcup.bat. В оболочке Windows введитеcup будет достаточно. Баш не работает таким образом, он хочет полное имя. Набравcup.bat решил проблему. (Я не смог запустить файл, так как, очевидно, bash не мог понять его содержимое)

Еще одна причина, чтобы перейти на шикарную игру ..

Спасибо @ за то, что указал мне правильное направление.

m Variable

\; C: \ Program Files \ Git \ bin

и теперь это работает!

кто попробовал все вышеперечисленные методы, включая системную среду Windows. переменные, .bashrc, .bashprofile и т. д. И они могут видеть правильный путь в 'echo $ PATH' ... У меня может быть решение для вас.

подавить ошибки, используяexec 2> / dev / null

Мой скрипт работает нормально, но выдает ошибки «команда не найдена» или «Каталог не найден», хотя, насколько я могу судить, пути были пустыми. Таким образом, если вы подавите эти ошибки (возможно, придется добавить 'set + e'), то это будет работать правильно.

в переменную $ PATH. Например, каталог приложения в программных файлах будет выглядеть таPATH=$PATH:/c/Program Files (x86)/random/application

Не делай этого:
PATH=$PATH:/c/Program\ Files\ \\(x86\\)/random/application/

Надеюсь это поможет

ве значения% Path%, из того, что я заметил, Git Bash видит только пользовательские переменные, а не системные переменные. Выполнив упомянутую процедуру, вы выставите вашу системную переменную в пользовательских переменных.

я узнал, что Git bash действительно использует PATH, но не последние пути, которые я недавно установил. Чтобы обойти эту проблему, я добавил в свою домашнюю (Windows) директорию файл с именем:

.bashrc

и содержание следующим образом:

PATH=$PATH:/c/Go/bin

потому что я устанавливал Go и этот путь содержал исполняемый файлgo.exe Теперь Git Bash смог распознать команду:

go

Возможно, в моем случае достаточно было бы перезагрузить систему, но я рад, что это решение работает в любом случае.

\ Users \ USERNAME, который называется config.bashrc, содержащий:

PATH=$PATH:/c/Program\ Files\ \(x86\)/Application\ with\ space

Теперь переместите файл в командной строке в правильное место:

mv config.bashrc .bashrc

вы можете выбрать опцию, показанную ниже, она поможет вам автоматически указать путь.

У меня получилось

Я изменил свой пользователь PATH, после чего я просто вышел из системы и снова вошел в систему.

Вот и все!git bash правильно загрузил новое значение PATH.

основная причина в том, что Git Bash не всегда может правильно проанализировать переменную% USERPROFILE%. Вместо того, чтобы делать это относительно C: \ Users \\, он получает значение C: \ Windows \ System 32 \ systemprofile \. После изменения его на полностью определенный адрес, он работает, и даже если я впоследствии верну его обратно, Git Bash по-прежнему имеет правильный путь по какой-то причине.

что перезапуск системы убедится, что git выбрал PATH, заданный в переменной окружения в windows, и другого автоматического способа не существует.

ема и задан путь переменной пользователя для моей рабочей области golang на моем компьютере с Windows 10. Когда я удалил избыточный путь к системной переменной и вышел из системы, а затем снова вошел в систему, я смог вызвать .exe-файлы в bash и вызвать go env с успехом.

Хотя на OP ответили, это еще одна проблема, которая может помешать bash увидеть ваши пути. Я только что снова протестировал bash с этой проблемой, и она, похоже, дает какой-то конфликт, который блокирует bash следовать по любому из путей.

ВАШ ОТВЕТ НА ВОПРОС