Ask Ubuntu is a question and answer site for Ubuntu users and developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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:


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

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?

share|improve this question
what does type -a pdflatex show? – glenn jackman May 27 '13 at 13:02
up vote 3 down vote accepted

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.

share|improve this answer

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
$ 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 
$ type acpidump 
acpidump is hashed (/usr/bin/acpidump)
$ hash -r                # clear cache
$ type acpidump 
acpidump is /home/peter/bin/acpidump
share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.