Windows e Git Bash: Bash PATH para ler a variável de sistema Windows% PATH%

Question

Adicionamos recentemente um diretório ao Windows PATH manualmente no Painel de controle - > Sistema - > Configurações avançadas do sistema - > Variáveis de ambiente - > Variáveis do usuário - > CAMINHO. (Windows 7, 64 bits.)

Após reiniciar e iniciar o cmd.exe, echo %PATH% indica que isso funcionou: vejo o diretório que adicionei recentemente na saída.

No entanto, depois de iniciar o Git Bash, a saída de echo $PATH não inclui esse diretório.

Eu poderia adicionar export PATH=$PATH:/c/my/path no meu bashrc, mas eu prefiro que o Git Bash pegue o PATH do Windows, então não preciso lembrar de adicionar caminhos a dois lugares. Como isso pode ser feito?

(Uma pergunta mais geral é, o que configura o $ PATH do Git Bash? Eu vejo algumas entradas repetidas em lugares diferentes, algumas coisas que estão no% PATH% do Windows estão no $ PATH do Git Bash mas não em outras. tudo acontece antes de eu receber o prompt do Git Bash que toca $ PATH?)

    

Answer 1

Uma sessão bash do msysgit git usa o script share/WinGit/Git Bash.vbs , que não acessa ou modifica a variável de ambiente PATH (como seria em este script vbs não relacionado, por exemplo )

Uma sessão bash do git será simplesmente adicionada na frente do seu atual PATH :

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

É possível que a sessão do mingw empacotada com o msysgit não considere um bin de outra instalação do mingw: você pode configurá-lo definindo outro diretório (mais simples) para o PATH e ver se ele ainda está visível em sua sessão bash do git. Se não, então é uma questão mais geral que diz respeito a todos os diretórios que você adicionaria ao PATH.

    

Answer 2

Aqui está minha pequena solução para um problema semelhante (MSYS2 bash no Windows 10).

A idéia é converter os caminhos necessários para caminhos no estilo Unix e anexá-los ao bash $ PATH, tudo feito em .bashrc.

Não anexe os caminhos necessários para o Win PATH. Em vez disso, crie um novo env var no Windows, como MSYS2_WINPATH, e acrescente todos os diretórios de caminho do Windows separados por ponto-e-vírgula a essa variável. Anexe% MSYS2_WINPATH% a% PATH%.

Agora insira isso no seu .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

Se o valor PATH for muito longo após a variável PATH do seu usuário ter sido concatenada na variável PATH do ambiente, o Windows falhará silenciosamente em concatenar a variável PATH do usuário.

Isso pode acontecer facilmente após a instalação de um novo software e adiciona algo ao PATH, quebrando, assim, o software instalado existente. Windows falha!

A melhor solução é editar uma das variáveis PATH no Painel de Controle e remover entradas que você não precisa. Em seguida, abra uma nova janela do CMD e veja se todas as entradas são mostradas em "echo% PATH%".

    

Answer 4

Tente mover o diretório para o início da sua variável de caminho. Eu tive o mesmo problema que você depois de instalar o p4merge. O diretório perforce foi adicionado ao caminho e o p4merge foi encontrado pelo cmd.exe, mas não pelo shell git (mingw). Após uma pesquisa infrutífera, tentei apenas editar a variável para que o diretório perforce aparecesse primeiro no meu caminho. Ativei o git shell e, voila, o diretório está incluído na saída de $ echo $path e $ p4merge abre o p4merge.

Isso é meio que uma resposta ruim, já que eu não entendo por que isso funciona, mas se a solução ajudar alguém, ótimo.