Bash se recusa a executar o binário correto

Question

Instalei a versão atual do texlive (2012), que instala seus binários em /usr/local/texlive/2011/bin/i386-linux/ . Em seguida, adicionei esse diretório à variável PATH, modificando o arquivo /etc/environment , já que quero isso instalado para todos os usuários:

PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/texlive/2012/bin/i386-linux"

Eu então comecei a remover os pacotes texlive apt-suite, já que eu estava recebendo erros ao tentar compilar .tex documentos que me mostraram que uma distribuição texlive 2009 veio pré-empacotada com meu Lubuntu 12.04.

Agora algo muito estranho acontece:

~ which pdflatex
/usr/local/texlive/2012/bin/i386-linux/pdflatex

Então parece que o binário está sendo encontrado. Ainda assim, acontece o seguinte:

~ pdflatex foo.tex
/usr/bin/pdflatex: File not found!

Por que está parecendo "n /usr/bin/ "? Isso é algum tipo de cache interno bash para locais binários (lembro vagamente de ter ouvido algo sobre isso)?

O que seria uma correção possível?

    

Answer 1

Muito provável /usr/bin/pdflatex é um link simbólico para o pacote que você acabou de remover, que, por sua vez, não existe . Tente ls -l /usr/bin/pdflatex para ver se aponta para outro arquivo. Se é um link simbólico quebrado (o alvo não existe) você pode simplesmente removê-lo e o próximo pdflatex no PATH deve ser executado.

which realmente procura o primeiro executável no PATH , que existe . Em outras palavras, se você ln -s /non-existing/path /usr/local/sbin/pdflatex será ignorado por which , mesmo que /usr/local/sbin seja o primeiro em PATH .

    

Answer 2

O Bash tem, de fato, um "cache" para programas pesquisados recentemente. Você pode usar hash -r para limpar esse cache em um shell. Alternativas:

• Basta fechar o shell atual e abrir um novo.
• Forneça o caminho completo, por exemplo: /usr/bin/pdflatex file.tex

which é um programa externo. Ele sempre reportará o programa como combinado no estado atual. Para investigar qual comando é executado pelo shell, use o type builtin.

Demonstração do cache:

$ which acpidump
/usr/bin/acpidump
$ type acpidump
acpidump is /usr/bin/acpidump
$ acpidump -h &>/dev/null       # trigger a lookup
$ type acpidump
acpidump is hashed (/usr/bin/acpidump)
$ mv ~/bin/acpidump{.x,}        # make acpidump available in PATH
$ which acpidump 
/home/peter/bin/acpidump
$ type acpidump 
acpidump is hashed (/usr/bin/acpidump)
$ hash -r                # clear cache
$ type acpidump 
acpidump is /home/peter/bin/acpidump