[tex-k] [tex-live] mktexlsr does not include $TEXMFLOCAL when refreshing

R (Chandra) Chandrasekhar chandra at ee.uwa.edu.au
Tue Mar 24 15:49:38 CET 2009

Zdenek Wagner wrote:

> mktexlsr /some/path rebuilds ls-R in /some/path while mktexlsr
> consults texmf.cnf and rebuilds ls-R in directories listed in
> TEXMFDBS. Probably "sudo mktexlsr" finds some other mktexlsr, not the
> one distributed with TeX Live, thus it finds different texmf.cnf and
> rebuilds ls-R in different directories. Try
> sudo which mktexlsr
> It will show you which mktexlsr was used.

Thank you for your quick reply. What you have pointed out certainly is 
the cause of the reported behaviour.

sudo which mktexlsr



whereas the one in the texlive path is at:



sudo /usr/local/texlive/2008/bin/x86_64-linux/mktexlsr

does indeed include the $TEXMFLOCAL directory.

In my .bashrc file, I have:

PATH=/usr/local/texlive/2008/bin/x86_64-linux:$PATH; export PATH
MANPATH=/usr/local/texlive/2008/texmf/doc/man:$MANPATH; export MANPATH
INFOPATH=/usr/local/texlive/2008/texmf/doc/info:$INFOPATH; export INFOPATH


which mktexlsr

gives me


So, it is the sudo that is changing the executable.

I suspect that I have three options:

1. Clear all executables in /usr/bin that have been superseded by those 
installed by by texlive. This is non-standard and difficult because some 
were put in by the kile package and other packages, and although I have 
removed kile for now, some residual packages might remain.

2. Ensure that the texlive executables are seen first by the superuser 
as well. Doe this mean that I have to include the above lines in 
/root/.bashrc as well? If so, are there any security implications?

3. Explicitly specify the mktexlsr to use by including the full path. 
This seems the neatest option at present.

I would appreciate advice on what would be the best option.



More information about the tex-k mailing list