Percebo que quando compilo uma compilação personalizada de um programa empacotado armazenado em , /usr/binpor exemplo /usr/bin/emacs, which emacsmostra o executável já existente em /usr/bin/emacs, /usr/local/bin/emacsembora /usr/local/binocorra anteriormente no meu arquivo PATH.
Eu preciso entrar e sair, ou abrir um novo screenquadro antes de which emacsmostrar o novo binário.
Isso é por causa de algum cache ou há algum recurso de segurança que faz com que o caminho existente seja referenciado até o login novamente?
EDITAR :
Para aqueles que consideram esta pergunta duplicada ou respondida por outras perguntas, por exemplo - Como faço para limpar o cache do Bash de caminhos para executáveis? , Qual é a finalidade do comando hash? , esta pergunta pergunta especificamente sobre um shell, não sobre bash, ou o hashcomando embutido bash(que eu não conhecia), apesar de ser o shell padrão na maioria dos sistemas.
Existem outros shells, por exemplo, zsho que eu uso, fish, ksh, eshell, kshe host de outros novos shells, por exemplo, oilshellchegando ao mercado, por assim dizer.
Então eu acho que essa questão deve ser por si só, sendo sobre shells em geral, não um shell em particular ou outro.
Se há uma razão para isso, a experiência ensinou que é a opção sensata, ou tem a ver com economia ou desempenho do que outras respostas podem elaborar.
Eu teria preferido que esta edição fosse um comentário, mas eles são limitados em tamanho.
Sim, o bash e outros shells mantêm uma tabela "hash" de comandos que ele pesquisou tentando tudo em sua variável PATH, para que não seja necessário verificar todas as vezes. As pessoas que fazem alterações, como você, no ambiente acharão o comando
hash -d NAMEútil, ou ohash -r. Estes são comandos bash, outros shells podem fazer as coisas de maneira um pouco diferente.Então,
pedirá ao bash para esquecer o caminho do emacs e
vai pedir para esquecer todos os caminhos. Eu costumo usar o último.