![](https://secure.gravatar.com/avatar/49e63acb01f2ca80efce7eed08310ce8.jpg?s=120&d=mm&r=g)
Tobias Burnus wrote:
Hi Hans,
Hans Hagen wrote:
you use an old luatools / luat-inp.lua; I updated now luat-inp.lua from the latest experimental cont-tmf.zip, however, that does not help.
a) luatools.lua does not use luat-inp.lua (and luatools.lua is up to date in TeX Live) Thus updating does not help. (Besides, without the texmfcnf file, luatools.lua cannot use any other file as one cannot search for it.)
luat-inp.lua is merged into luatools in order to make in 'stand-alone' luatools --selfupdate could do that depending on the fact if your system works i really cannot find the code in my luatools (i'll send it to you)
b) Following UNIX symbolic links does not seem to work under Linux. I played around with luat-inp.lua and it does not work.
hm, maybe taco knows ..
c) Werner asks: Why is the KPSE library not used? I have to agree - KPSE uses the compile-time defaults for the path and thus should provide the correct default TEXMFCNF directory. Afterwards, I'm fine using a non-KPSE method. How about using KPSE as backup method if it doesn't find a config file otherwise?
several reasons: (1) in spite of promises, kpse was never extended to support other input methods (2) the lua library can handle things like zip files, url's, soon sockets, etc. i don't want to be limited in context (3) the lua library is (once the database is there) faster than kpse (4) when used in scripts we only load the databsse once so in the case of context luatools (or mtxrun) can run scripts that themselves need the database without a reload (ok, to some extend that can also be done with the kpse lib) (5) i have control over the lua based library -)
For "luatex" itself (contrary to "luatools") there is no problem as luatex uses the compile-time path and finds the texmfcnf file.
hm, but since luatools is ran using texlus (which is luatex) the same should apply - make sure that luatools is run by texlua and not by lua itself - don't use a stub, just rename luatools.lua to luatools and mtxrun.lua to mtxrun (so, no texmfstart like extra stubs which would slow down things considerably)
Back to (b): The symbolic links support in luat-inp.lua seems only to work if your "directory" is a symbolic link but not if the file is a symbolic link, e.g. "foo/bin -> /usr/local/bar-bin" then for "foo/bin/file" doing "chdir(foo/bin)" makes sense as then "currentdir()" prints "/usr/local/bar-bin" but this does not work for /usr/bin/luatools -> ../share/texmf/..../luatools.lua as the chdir(/usr/bin) makes no difference.
One really needs "posix.readlink" support, which is not in my texlua. Or, alternative 2, if path ends in bin, try "../share/texmf" as my old patch does. Or one indeed uses KPSE: kpse.set_program_name('luatex') local kpse_result1 = kpse.find_file(input.luaname,'cnf',true) local kpse_result2 = kpse.find_file(input.cnfname,'cnf')
I'm also open for other suggestions.
once we have the same luatools we can look into the share thing Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------