[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:
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
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