Observação: Eu tenho um executável chamado foo, localizado em / b / foo. Ele é compilado em um cabeçalho antigo de uma biblioteca dinâmica, fazendo com que ele seja segfault quando executado:
$ foo
Segmentation fault. // Expected behaviour.
Agora, eu compilo uma nova versão do foo para / a / foo com a nova biblioteca dinâmica que deve ser executada muito bem. Diretório a / está no meu $ PATH antes de b /, então / a / foo deve ser selecionado:
$ which foo
/a/foo
Quando executo o foo, acontece o seguinte:
$ foo
Segmentation fault.
Portanto, parece que / b / foo é executado, enquanto que "which" me diz que / a / foo deve ser executado. Para tornar as coisas mais estranhas, quando executo o caminho completo $ (which / a / foo), as coisas funcionam bem:
$ /a/foo
OK!
$ cp /a/foo .
$ ./foo
OK!
Para ir ainda mais longe, se eu excluir agora / a / foo:
$ rm /a/foo
Então / b / foo certamente deve ser escolhido, certo?
$ which foo
/b/foo
$ foo
bash: /a/foo: No such file or directory
$ $(which foo)
Segmentation fault. // Expected result.
Não!
Correção: Fonte .bash_profile e .bashrc e o problema desaparece.
Reprodutibilidade: Toda vez. Basta remover / a / foo, source ~ / .bash_profile, criar / a / foo e a observação acima ocorrerá novamente.
Pergunta: Alguém tem uma idéia do que deu errado aqui?
Hipótese: "which" está atualizado, mas o sistema escolhe com base em "o que costumava ser o caso". No meu exemplo acima, o / a / foo ainda não existia quando o terminal foi aberto: eu tinha acabado de criá-lo. Portanto, quando / a / foo foi criado, "which" detectou / a / foo, mas o sistema ainda escolheu / b / foo, porque estava de alguma forma fora de sincronia? Mas por que o sistema está fora de sincronia?
O Bash armazena em cache a localização dos comandos. Use hash foo para forçá-lo a atualizar o cache.
Além disso, which é um comando separado que não informa onde o seu shell está realmente procurando; ele apenas consulta a variável de ambiente $PATH . No bash, você deve usar type :
$ type foo
foo is hashed (/a/foo)