![](https://secure.gravatar.com/avatar/4f90ced6bd47c80395b33c0fde81a0d0.jpg?s=120&d=mm&r=g)
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.) b) Following UNIX symbolic links does not seem to work under Linux. I played around with luat-inp.lua and it does not work. 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? For "luatex" itself (contrary to "luatools") there is no problem as luatex uses the compile-time path and finds the texmfcnf file. 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. Tobias