2

I have a small problem with the package currfile and the command \currfileabspath. When compiling the file using (pdf|xe)latex I get the expected result, but if I use lualatex it adds ./ to the absolute path of the file. I'm using TeXLive 2018 (updated) in Fedora 29, the working directory looks like this:

[pablo@fedora forum] $ pwd
/home/pablo/forum
[pablo@fedora forum] $ ls -lha
total 12K
drwxrwxr-x.  2 pablo pablo 4,0K feb 17 13:11 .
drwx------. 43 pablo pablo 4,0K feb 17 13:10 ..
-rw-rw-r--.  1 pablo pablo  187 feb 17 13:03 test.tex

My MWE (test.tex) is this:

\documentclass{article}
\usepackage[abspath]{currfile}
\setlength{\parindent}{0pt} 
\begin{document}
\texttt{\jobname.pdf} created from file \texttt{\currfileabspath}%
\end{document}

I use the following line to compile it:

$ pdflatex -recorder test.tex

with which I obtain:

test.pdf created from file /home/pablo/forum/test.tex

which is correct, but if I change it to:

$ lualatex -recorder test.tex

I get

test.pdf created from file /home/pablo/forum/./test.tex

How can I solve this? regards

2 Answers2

4

Removing the period is easy:

\documentclass{article}
\usepackage[abspath]{currfile}
\usepackage{expl3}
\ExplSyntaxOn
\regex_replace_once:nnN{\.\/}{}\currfileabspath
\ExplSyntaxOff
\setlength{\parindent}{0pt}
\begin{document}
\texttt{\jobname.pdf} created from file 
\currfileabspath%
\end{document}

But imho it would be better if currfile would do this, when lualatex is used, as the period and the slash is also in other commands.

Ulrike Fischer
  • 327,261
4

You can easily get the absolute path in LuaTeX using the FFI and a platform-dependent function. On POSIX-based systems you can use the realpath() function, on Windows you would use _fullpath (I think).

Because it uses the FFI you have to enable --shell-escape.

In tex.sprint I use the first argument -2 to switch to verbatim catcodes, in case the path contains any characters which are treated special by TeX, such as {}$%#.

\documentclass{article}
\directlua{
local ffi = assert(require"ffi")

ffi.cdef[[

char *realpath(const char *path, char *resolved_path);
]]

function realpath(path)
    local p = ffi.C.realpath(path, ffi.NULL)
    if p \string~= ffi.NULL then
        return ffi.string(p)
    end
    return nil
end
}

\def\currfileabspath{%
  \directlua{tex.sprint(-2, realpath(status.filename))}%
}

\begin{document}
\currfileabspath
\end{document}
Henri Menke
  • 109,596
  • This is very interesting. The documentation (e,g. https://luajit.org/ext_ffi_tutorial.html) suggests that this FFI is associated with LuaJIT, but I tested your code and it works. Would this work with larger amounts of C code, or just with small snippets? Also, when I compiled the code, there was no visible C compilation, so I don't understand how this worked without C compilation. – Faheem Mitha Nov 27 '21 at 15:56
  • 1
    @FaheemMitha At some point in the past Facebook ported the LuaJIT FFI as a library to PUC-Rio Lua which is included in LuaTeX. A foreign-function interface (FFI) doesn't need a compilation step, because it only translates function calls on the fly. You can only put function declaration into the ffi.cdef block, not function definitions. I've also posted a relevant answer on SO some time ago: https://stackoverflow.com/questions/53805913/how-to-define-c-functions-with-luajit – Henri Menke Nov 28 '21 at 13:56
  • This is actually in the Lua Posix library as realpath, and that is slightly preferable to wrapping the raw C realpathfunction directly with no error checking. For example, if there is no file match, realpath returns a null pointer. At the Lua level (or TeX level), this segfaults, which isn't very helpful. The posix.realpath function does a bit better than that, though I don't particularly like the way it's written. – Faheem Mitha Dec 03 '21 at 15:56
  • @FaheemMitha True, calling C functions via FFI is always playing with fire because a segfault will crash the Lua interpreter and take the TeX engine with it. On the other hand luaposix is not bundled with LuaTeX and because LuaTeX uses KPSE instead of Lua's own path search it's a real pain to use third-party libraries with LuaTeX. The libc on the other hand is trivially available, even on Windows I believe because LuaTeX for Windows is built against mingw32. – Henri Menke Dec 03 '21 at 17:10
  • It's not such a pain. You just need to use luapackageloader and add some paths package.cpath and package.path. It could be made easier. It seems that it isn't made so for security policy reasona. – Faheem Mitha Dec 03 '21 at 18:31