Support invoking Texdoc with absolute paths

[kberry]

when latest release is invoked with an absolute path, I get a fatal error:
$ /usr/local/texlive/pretest/bin/x86_64-linux/texdoc graphicx

/usr/local/texlive/pretest/bin/x86_64-linux/texdoc:15: attempt to index field 'cli' (a nil value)

[wtsnjp]

Are the all other Texdoc's script files in your kpse search space updated as well? The latest version updates all script files entirely, so you cannot use texdoc (which is equivalent to texdoc.tlu) with files in an older version. In that case, the situation is completely intentional.

[kberry]

as you might guess from the path, i am using texdoc from the tex live pretest. as far as i can see that is exactly what is on ctan.

are you sure the code works when invoked by an absolute path (to a symlink that points to the actual script)? the evidence appears not.

also, as a separate issue, i don't think a lua error ("attempt to index field") is what a user should see. seems like it would be better to check for cli being nil and giving an error message that might be comprehensible.

[wtsnjp]

Yes, I am sure it can be invoked by an absolute path because I am testing Texdoc in that way.

texdoc/Rakefile

Line 196 in 5f3f801

sh "texlua #{TEXDOC_TLU} #{options[:args]}"

where TEXDOC_TLU is an absolute path to the texdoc.tlu.

Only you have to do is to put the latest version of texdoclib in your kpse search space. Otherwise, even if it doesn't lead to an error, you are using only the small wrapper (texdoc.tlu) from the latest version, and using all core implementation (texdoclib.tlu and its submodules) from an older version...

Maybe you are right about the "attempt to index field" error, so I will think about using the assert() to prevent it.

[aminophen]

Hi Karl & Takuto,

for me (on macOS) the full path works, with the TL19 pretest frozen:

$ /usr/local/texlive/2019dev/bin/x86_64-apple-darwin/texdoc graphicx

[kberry]

your invocation above is different from running ${TEXDOC_TLU} directly from the shell. You are wrapping it in invocations of sh and texlua.

Anyway, given Hironobu's result (thanks), I suppose it works for me. it is inexplicable to me. As i said, i have exactly what's in the pretest, presumably exactly what Hironobu has (misformatted by github):
$ ls -l /usr/local/texlive/pretest/texmf-dist/scripts/texdoc -rwxr-xr-x 1 karl root 432 Mar 28 13:58 texdoc.tlu* -rwxr-xr-x 1 karl root 3216 Mar 28 13:58 texdoclib-alias.tlu* -rwxr-xr-x 1 karl root 6725 Mar 28 13:58 texdoclib-cli.tlu* -rwxr-xr-x 1 karl root 19240 Mar 28 13:58 texdoclib-config.tlu* -rwxr-xr-x 1 karl root 4135 Mar 28 13:58 texdoclib-const.tlu* -rwxr-xr-x 1 karl root 9719 Mar 28 13:58 texdoclib-score.tlu* -rwxr-xr-x 1 karl root 24456 Mar 28 13:58 texdoclib-search.tlu* -rwxr-xr-x 1 karl root 3329 Mar 28 13:58 texdoclib-util.tlu* -rwxr-xr-x 1 karl root 9565 Mar 28 13:58 texdoclib-view.tlu* -rw-r--r-- 1 karl root 1319 Mar 28 13:58 texdoclib.tlu

Meanwhile, I'm sorry, but the two-line wrapper is incomprehensible to me. How can I get it to report where it is looking? It should be looking for in the same tree as $0, which might be different than PATH. We go to a lot of trouble to make that be the case for most everything. I don't know how to tell if it's doing that or not.

But anyway, ok, if I explicitly put only the pretest dir in the path:
env PATH=/usr/local/texlive/pretest/bin/x86_64-linux:/usr/bin texdoc graphicx
it behaves ok; also with the absolute path, that is,
env PATH=/usr/local/texlive/pretest/bin/x86_64-linux:/usr/bin /usr/local/texlive/pretest/bin/x86_64-linux/texdoc graphicx. So I guess it is about PATH rather than absolute paths.

Sigh.

[e-kwsm]

But anyway, ok, if I explicitly put only the pretest dir in the path

You should prepend /usr/local/texlive/pretest/bin/x86_64-linux to PATH.
I guess

texdoc/script/texdoc.tlu

Line 1 in 632c792

#!/usr/bin/env texlua

invokes older, e.g. TL2018, texlua in your system.

[kberry]

yes, thanks. as i said above, my point is that it should not be necessary to set PATH to get the right thing to happen when invoking via an absolute path. It isn't for virtually any other script or program in TL any more, and it is quite helpful for users. Even more so with texdoc than most. I hope something can look at $0 and make the necessary adjustments. maybe it would be easier if the wrapper was not itself written in (tex)lua.

[wtsnjp]

Setting PATH is only one way to "put the latest version of texdoclib in your kpse search space". There are many other approaches to achieve it (I guess you know how to do.)

The wrapper always loads $(kpsewhich -progname=texdoc texdoclib.tlu), which is not that much incomprehensible, I believe.

[kberry]

That line appears nowhere in texdoc.tlu, as far as I can see. The "incomprehensible" part is what path is used by the Lua require statement, local texdoc = require('texdoclib'), and whether it is possible to view/alter that path.

anyway, whatever.

[wtsnjp]

Can I help you further for this? Or is it all clear for you now?

[kberry]

hi takuto - well, not much is clear to me, but never mind that : ).

the real problem that remains is that PATH should not need to be set. if invoked as /some/path/.../texdoc, it would be very helpful if texdoc could "auto-self-locate" based on $0, that is, to /some/path/...

[wtsnjp]

As I stressed, you don't have to change the PATH for testing Texdoc. My recommendation is setting TEXMFHOME properly, just like instructed in the Section "How to Install the Develop Version" of our README.

Invoking from a shell wrapper will not solve the whole problem because Texdoc has submodules (texdoclib-*.tlu). Even if we replace the wrapper to a shell script, the submodules must be loaded inside Lua. Here, the same problem will come up. So, this problem cannot be simply solved by using a shell script with $0. We have to find a way to load Lua modules by relative paths. I considered to do this several times, but I haven't found a secure way to do it yet.

For now, I concluded that to keep using the kpse library to load both the module and its submodules is the simplest and consistent. Otherwise, the architecture and the loading rule will be much more complicated.

[kberry]

the issue isn't testing/debugging, but just use. like most people, i have many tl trees, e.g., /usr/local/texlive/{2018,dev,pretest,...} and it is useful to be able to invoke /usr/local/texlive/whatever/bin/someprog without changing PATH, TEXMFHOME, or anything else. for that matter, being able to do that would also make debugging a lot easier.

how about having the top-level texdoc script look at $0, and if it is not already $TEXMFMAIN, putenv the value to TEXMFCONFIG? (or something like that.) then it seems like kpse can still be used for lookup, but texdoc would adapt to how it is invoked. and since texdoc does not otherwise use TEXMFCONFIG ... just a thought.

[wtsnjp]

Finally, I see your point.

I have a question: by invoking Texdoc with an absolute path, say /usr/local/texlive/dev/<...>/texdoc, which tl tree do you want to search with it? (A) /usr/local/texlive/dev or (B) the current tl tree, which is set by your environment?