[tex-live] $TEXMFHOME not working right

Reinhard Kotucha reinhard.kotucha at web.de
Sat May 15 19:06:02 CEST 2010

On 14 May 2010 Robin Fairbairns wrote:

 > Norbert Preining <preining at logic.at> wrote:
 > > On Do, 13 Mai 2010, Joel C. Salomon wrote:
 > > > chesky at derrial:~$ mktexlsr --verbose `kpsewhich --expand-var='$TEXMFHOME'`
 > > > mktexlsr: Updating /home/chesky/texmf/ls-R...
 > > > mktexlsr: Done.
 > > > 
 > > > The ls-R file is created, but .sty files are still not found for
 > > > typesetting.
 > > 
 > > No need for that, or even counter-productive. TEXMFHOME is searched
 > > for without ls-R files present.
 > indeed.  however, if you access your home directory over nfs (as
 > *all* my users at work do) it has the potential to seriously slow
 > things down.  scanning directories over nfs this way is regularly
 > the source of support calls about "tex suddenly slow" (after
 > loading something like pgf).

Ideally there are only very few files in TEXMFHOME because TeX Live is
very complete.  However, the situation might be different if users
want to use beta versions of huge packages.  And installing user
specific files locally is quite unfortunate if HOME is on a server.

What you can do is to add TEXMFHOME to TEXMFDBS.  This has no effect
and files are still searched in the file system, at least until a user
runs texhash.  Then he has to keep the ls-R file up-to-date or remove

One can't assume that even without TEXMFHOME in TEXMFDBS there will
never be an ls-R file in TEXMFHOME.  There will always be one after
running getnonfreefonts.  This is not actually desired and I wasn't
even aware of until now.  The reason is that texhash ignores TEXMFDBS
if it's called with an argument.  I didn't even know that this works
at all:

  $ texhash /usr/local/share/emacs
  texhash: Updating /usr/local/share/emacs/ls-R... 
  texhash: Done.

getnonfreefonts[-sys] calls texhash with an argument in order to avoid
creating texmf-dist/ls-R each time because this consumes a lot of time
and getnonfreefonts[-sys] already knows where it installed the fonts.

The behaviour of texhash is a bit unfortunate.  It would be better to
obey TEXMFDBS always and add a --force option which allows for
creating ls-R files in arbitrary directories.

Anyway, TeX Live versions prior to TeX Live 2007 had:


Every user had to run texhash after adding files and nobody
complained.  The setting of TEXMFDBS were changed due to a bug in
fmtutil.  BTW, this bug was reported by Donald Knuth himself.  We were
clueless but after I encountered the same problem, I proposed to
remove TEXMF[SYS]VAR from TEXMFDBS as a simple workaround.  The
problem was that fmtutil appended newly created format files to ls-R
files without scanning the whole directory tree.  This worked fine in
the past but with teTeX-3 it wasn't as reliable as before.

When I discussed the TEXMF[SYS]VAR issue with Karl, we also discussed
how to treat TEXMFHOME.  We couldn't set "TEXMFDBS = $TEXMF" anymore
because we had to treat TEXMF[SYS]VAR as an exception anyway.

Regarding TEXMFHOME, we assumed that there will be only a few files
and it's not worthwhile to create an ls-R file in this directory.
We thought that removing TEXMFHOME from TEXMFDBS makes life easier.

However, nowadays I think that this was not a good decision.  It seems
that creating a TDS compliant directory structure somtimes causes
problems but most users are aware of texhash already.

Therefore I wouldn't object if the old behaviour is restored.


Reinhard Kotucha			              Phone: +49-511-3373112
Marschnerstr. 25
D-30167 Hannover	                      mailto:reinhard.kotucha at web.de
Microsoft isn't the answer. Microsoft is the question, and the answer is NO.

More information about the tex-live mailing list