1

I've installed the current version of texlive (2012), which installs its binaries into /usr/local/texlive/2011/bin/i386-linux/. I subsequently added this directory to the PATH variable by modifying the /etc/environment file, since I want this installed for all users:

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

I then proceeded to remove the texlive apt-suite packages, since I was getting errors when trying to compile .tex documents that showed me a texlive 2009 distribution came prepackaged with my Lubuntu 12.04.

Now something pretty strange happens:

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

So it seems the binary is being found. Still, the following happens:

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

Why is it looking ìn /usr/bin/? Is this some kind of bash internal cache for binary locations (I vaguely remember hearing something about this)?

What would be a possible fix?

2

2 Answers 2

7

Bash has indeed a "cache" for recently looked up programs. You can use hash -r to clear this cache in a shell. Alternatives:

  • Just close the current shell and open a new one.
  • Supply the full path, for example: /usr/bin/pdflatex file.tex

which is an external program. It will always report the program as matched in the current state. To investigate which command is executed by the shell, use the type builtin.

Demonstration of the 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
3

Very likely /usr/bin/pdflatex is a symbolic link to the package you just removed, which in turn doesn't exist. Try ls -l /usr/bin/pdflatex to see if it points to another file. If it's a broken symlink (the target doesn't exist) you can simply remove it and the next pdflatex in the PATH should be run.

which actually looks for the first executable in the PATH which exists. In other words, if you ln -s /non-existing/path /usr/local/sbin/pdflatex it will be ignored by which, even though /usr/local/sbin is first in the PATH.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .