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?

[norbusan]

Karl's proposal is that the texdoclib-* files are taken from the same tree as the initlally called texdoc.

This is probably somehow contrary to your idea of having a minimal texdoc.tlu -- according to the comments in that file -- so that updates can easily be copied say to TEXMFHOME but the texdoc binary is still in some main tree.

But I agree with Karl, that if one calls texlua PATH/TO/texdoc.tlu I would expect that all the lib files are taken from the same tree.

Other trees searched should not be removed. Thus Karl proposed to

• check for $0 base dir being part of TEXMFMAIN
• if not, add it to TEXMFCONFIG or a similar variable so that searching documents is done in the other trees, too

At least that is my intepretation

[wtsnjp]

@norbusan thanks for the detailed explanation.

Well, for clarification, having a minimal texdoc.tlu is not my idea. The loading mechanism of Texdoc (which don't allow us easily to self-locate with absolute path) hasn't been changed since I began maintenance. So, basically, we are now talking about a new feature.

Anyway, I will do some experiments to see if this new policy work well for searching documentation:

• check for $0 base dir being part of TEXMFMAIN
• if not, add it to TEXMFCONFIG or a similar variable so that searching documents is done in the other trees, too

(Unfortunately, Texdoc uses TEXMFCONFIG for finding its configuration files, so maybe we should use another variable.)

From this solution, your answer to this question would be "both (A) and (B)", right?

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?

[norbusan]

Ahh, the minimal texdoc idea is thus from back then, didn't know.

Yes, I guess (A) and (B), but Karl will probably comment later tonight.

[wtsnjp]

In case the answer is "both (A) and (B)", we have to decide which one to give a higher priority for the searching result. At least for loading Texdoc's modules, we have to put (A) first. Otherwise, the modules from another tree will be loaded, which is the current behavior ;)

[wtsnjp]

In addition, we also have to think about which configuration file to load.

In short, before to make it possible to invoke Texdoc with absolute paths, we have to decide the following policies:

• Which tl tree(s) to search for documentation? (A), (B), or both of them?
• If we want to search for multiple tl trees, which should get higher priority and how high?
• Which tl tree(s) we look for Texdoc's configuration files? (A), (B), or both?

[wtsnjp]

If we are going to search multiple tl trees, concerning the existence of aliases and adjscores, we might want to apply corresponding configuration files, which is in the target tl trees (applying aliases in texdoc.cnf in the tree (A) for documentation in (A), and the same for the tree (B)).

This will be far more complicated specification (only for supporting absolute path invoking, which is somehow advanced and rare usage). Now I think that to restrict Texdoc to search for a single tl tree (just one of (A) or (B)) is a better option.

[kberry]

as far as i'm concerned, /some/path/texdoc should only use the tree for /some/path. it should be as if the user had done PATH=/some/path texdoc.

i forgot about texdoc using TEXMFCONFIG. but a better-i-think idea is to putenv TEXMFMAIN, if $0 is not already under the pre-existing TEXMFMAIN. Then nothing else changes, maybe.

thanks.

[wtsnjp]

as far as i'm concerned, /some/path/texdoc should only use the tree for /some/path. it should be as if the user had done PATH=/some/path texdoc.

Ok, I took that you are expecting to search the (A) tree, which the invoked Texdoc belongs to, for both documents and configurations. I think that behavior is natural and doable.

To summarize briefly, the new specification will be something like this:

• Texdoc must be installed inside a TeX Live tree, following TDS. It is not a stand-alone program.
• Texdoc always uses its configuration files in the TeX Live tree no matter how it is invoked.
• Texdoc always search for the documentation in the TeX Live tree no matter how it is invoked.

We'll see which implementation is the best.

[norbusan]

Besides that is TDS trees and unrelated to TeX Live, yes ;-)

[wtsnjp]

It is almost unrelated to TeX Live, but technically speaking, ordinally (without a shipped cache file) it requires texlive.tlpdb, which means it somehow requires to be in "TeX Live". Anyway, it is not so important here.

[kberry]

agreed with the new spec. thanks for looking into this.

[wtsnjp]

Currently, I'm doing an experiment for this.

a better-i-think idea is to putenv TEXMFMAIN, if $0 is not already under the pre-existing TEXMFMAIN. Then nothing else changes, maybe.

Setting TEXMFMAIN doesn't work because the variable is not in the TEXMF. Thus, changing the value of TEXMFMAIN will affect neither for looking up the texdoc library nor for searching documents.

Since texdoc uses TEXMFCONFIG and we don't want to use it, I came up with using the TEXMFAUXTREES variable. Then, I modified the texdoc.tlu as follows:

#!/usr/bin/env texlua

-- texdoc.tlu: the main program of texdoc
--
-- The TeX Live Team, GPLv3, see texdoclib.tlu for details

-- Note: we keep this file small as much as possible so that make it easier
--       to install a new version of texdoc in TEXMFHOME.

local lfs = require('lfs')
local kpse = require('kpse')

-- setup kpse library
kpse.set_program_name(arg[-1], 'texdoc')

-- get actual file path
local function actual_file(p)
  local t = lfs.symlinkattributes(p).target
  if t ~= nil then
    return actual_file(t)
  else
    return p
  end
end
local file = actual_file(arg[0])

-- set TEXMFAUXTREES if the file is not in TEXMFMAIN
local texmf = file:match('^(.*/texmf[^/]*)/scripts/texdoc/texdoc.tlu$')
if texmf ~= nil then
  if texmf ~= kpse.var_value('TEXMFMAIN') then
    os.setenv('TEXMFAUXTREES', texmf .. ',')
    print(string.format('DEBUG: TEXMFAUXTREES set to "%s"',
      kpse.var_value('TEXMFAUXTREES')))
  end
end

-- load the library and execute
local texdoc = require('texdoclib')
assert(texdoc.cli, 'Internal error: Texdoc is not installed properly.')
texdoc.cli.exec()

-- vim: ft=lua:

Under this setup, if and only if the actual file (after resolving symbolic links recursively) is not under current TEXMFMAIN, TEXMFAUXTREES will be set to the TEXMF tree which the actual file belongs to.

This works pretty well in my environment:

$ texlua ~/repos/tug.org/Master/texmf-dist/scripts/texdoc/texdoc.tlu -dfiles -lM texlive-en
DEBUG: TEXMFAUXTREES set to "/Users/asakura/repos/tug.org/Master/texmf-dist,"
texdoc debug-version: /Users/asakura/repos/tug.org/Master/texmf-dist/scripts/texdoc/texdoclib.tlu v3.1
texdoc debug-files: Configuration files are:
texdoc debug-files: not found	/Users/asakura/repos/tug.org/Master/texmf-dist/texdoc/texdoc-x86_64-darwin.cnf
texdoc debug-files: active	/Users/asakura/repos/tug.org/Master/texmf-dist/texdoc/texdoc.cnf
texdoc debug-files: not found	/Users/asakura/repos/tug.org/Master/texmf-dist/texdoc/texdoc-dist.cnf
texdoc debug-files: not found	/Users/asakura/Library/texlive/2019/texmf-var/texdoc/texdoc-x86_64-darwin.cnf
texdoc debug-files: not found	/Users/asakura/Library/texlive/2019/texmf-var/texdoc/texdoc.cnf
texdoc debug-files: not found	/Users/asakura/Library/texlive/2019/texmf-var/texdoc/texdoc-dist.cnf
texdoc debug-files: not found	/Users/asakura/Library/texmf/texdoc/texdoc-x86_64-darwin.cnf
texdoc debug-files: disabled	/Users/asakura/Library/texmf/texdoc/texdoc.cnf
texdoc debug-files: disabled	/Users/asakura/Library/texmf/texdoc/texdoc-dist.cnf
texdoc debug-files: not found	/usr/local/texlive/2019/texmf-dist/texdoc/texdoc-x86_64-darwin.cnf
texdoc debug-files: disabled	/usr/local/texlive/2019/texmf-dist/texdoc/texdoc.cnf
texdoc debug-files: not found	/usr/local/texlive/2019/texmf-dist/texdoc/texdoc-dist.cnf
texlive-en	5.5	/Users/asakura/repos/tug.org/Master/texmf-dist/doc/texlive/texlive-en/texlive-en.pdf
texlive-en	5.5	/usr/local/texlive/2019/texmf-dist/doc/texlive/texlive-en/texlive-en.pdf
texlive-en	5.5	/Users/asakura/repos/tug.org/Master/texmf-dist/doc/texlive/texlive-en/texlive-en.html
texlive-en	5.5	/usr/local/texlive/2019/texmf-dist/doc/texlive/texlive-en/texlive-en.html
texlive-en	1.7	/Users/asakura/repos/tug.org/Master/texmf-dist/doc/texlive/texlive-en/README
texlive-en	1.7	/usr/local/texlive/2019/texmf-dist/doc/texlive/texlive-en/README
texlive-en	1.6	/Users/asakura/repos/tug.org/Master/texmf-dist/doc/texlive/texlive-en/archive/changemail
texlive-en	1.6	/usr/local/texlive/2019/texmf-dist/doc/texlive/texlive-en/archive/changemail

According to texmf.cnf, TEXMFAUXTREES is a very special variable for tlmgr, so this solution is a bit tricky. However, considering the facts (1) that invoking texdoc which is not in TEXMFMAIN is mainly debugging purpose and (2) that setting TEXMFAUXTREES locally for texdoc will not affect other programs, it is just fine to use TEXMFAUXTREES. Right?

[kberry]

using TEXMFAUXTREES looks ok, but how about doing the setenv on TEXMFDIST? I don't know why I suggested TEXMFMAIN, since TEXMFDIST is the one used in the search paths.

That way, in your example above,the /usr/local/texlive/2019 tree wouldn't be in the results at all, which seems better to me, per your description a couple comments ago? thanks ...

[wtsnjp]

I thought the texdoc.tlu could be in texmf-* other from texmf-dist, so set TEXMFDIST to such a value sounds a bit strange, but it seems to temporary set it is not bad. Actually, we can get the better result as you mentioned:

$ texlua ~/repos/tug.org/Master/bin/x86_64-darwin/texdoc -lM texlive-en
DEBUG: TEXMFDIST set to "/Users/asakura/Develop/tug.org/Master/texmf-dist"
texlive-en	10.0	/Users/asakura/Develop/tug.org/Master/texmf-dist/doc/texlive/texlive-en/texlive-en.pdf
texlive-en	10.0	/Users/asakura/Develop/tug.org/Master/texmf-dist/doc/texlive/texlive-en/texlive-en.html
texlive-en	1.7	/Users/asakura/Develop/tug.org/Master/texmf-dist/doc/texlive/texlive-en/README
texlive-en	1.6	/Users/asakura/Develop/tug.org/Master/texmf-dist/doc/texlive/texlive-en/archive/changemail

No, it doesn't work well. It is good for the result but not good for searching texdoc itself. In the above, I forgot uninstalling the dev version in TEXMFHOME. Without it, the invoke will result in an error:

$ texlua ~/repos/tug.org/Master/texmf-dist/scripts/texdoc/texdoc.tlu -dfiles -lM texlive-en
DEBUG: TEXMFDIST set to "/Users/asakura/Develop/tug.org/Master/texmf-dist"
...epos/tug.org/Master/texmf-dist/scripts/texdoc/texdoc.tlu:40: module 'texdoclib' not found:
	no field package.preload['texdoclib']
	[kpse lua searcher] file not found: 'texdoclib'
	[kpse C searcher] file not found: 'texdoclib'

So, I would like to go for setting both TEXMFAUXTREES (for texdoc itself) and TEXMFDIST (for the documents search). This way, we can get the ideal result:

$ texlua ~/repos/tug.org/Master/texmf-dist/scripts/texdoc/texdoc.tlu -dfiles -lM texlive-en
DEBUG: TEXMFAUXTREES set to "/Users/asakura/Develop/tug.org/Master/texmf-dist,"
DEBUG: TEXMFDIST set to "/Users/asakura/Develop/tug.org/Master/texmf-dist"
texdoc debug-version: /Users/asakura/Develop/tug.org/Master/texmf-dist/scripts/texdoc/texdoclib.tlu v3.1
texdoc debug-files: Configuration files are:
texdoc debug-files: not found	/Users/asakura/Develop/tug.org/Master/texmf-dist/texdoc/texdoc-x86_64-darwin.cnf
texdoc debug-files: active	/Users/asakura/Develop/tug.org/Master/texmf-dist/texdoc/texdoc.cnf
texdoc debug-files: not found	/Users/asakura/Develop/tug.org/Master/texmf-dist/texdoc/texdoc-dist.cnf
texdoc debug-files: not found	/Users/asakura/Library/texlive/2019/texmf-var/texdoc/texdoc-x86_64-darwin.cnf
texdoc debug-files: not found	/Users/asakura/Library/texlive/2019/texmf-var/texdoc/texdoc.cnf
texdoc debug-files: not found	/Users/asakura/Library/texlive/2019/texmf-var/texdoc/texdoc-dist.cnf
texdoc debug-files: not found	/Users/asakura/Library/texmf/texdoc/texdoc-x86_64-darwin.cnf
texdoc debug-files: disabled	/Users/asakura/Library/texmf/texdoc/texdoc.cnf
texdoc debug-files: not found	/Users/asakura/Library/texmf/texdoc/texdoc-dist.cnf
texdoc debug-files: not found	/Users/asakura/Develop/tug.org/Master/texmf-dist/texdoc/texdoc-x86_64-darwin.cnf
texdoc debug-files: disabled	/Users/asakura/Develop/tug.org/Master/texmf-dist/texdoc/texdoc.cnf
texdoc debug-files: not found	/Users/asakura/Develop/tug.org/Master/texmf-dist/texdoc/texdoc-dist.cnf
texlive-en	5.5	/Users/asakura/Develop/tug.org/Master/texmf-dist/doc/texlive/texlive-en/texlive-en.pdf
texlive-en	5.5	/Users/asakura/Develop/tug.org/Master/texmf-dist/doc/texlive/texlive-en/texlive-en.html
texlive-en	1.7	/Users/asakura/Develop/tug.org/Master/texmf-dist/doc/texlive/texlive-en/README
texlive-en	1.6	/Users/asakura/Develop/tug.org/Master/texmf-dist/doc/texlive/texlive-en/archive/changemail

BTW, I noticed that the actual_file() logic I used in the above does not work well for relative paths (symlinks). Unfortunately, at this point, the lfs library does not have realpath() (cf. PR #85 on their repo).

The easiest workaround is calling the systems' realpath command. This way only works for UNIX-like systems but not for others, most notably not for Windows (also, it seems some UNIX systems do not have realpath). I think we don't have to support all platforms for this "invoking with absolute paths / without switching texmf" feature.

Or do you have a better idea fo realpath alternative?

[kberry]

setting both envvars sounds ok to me.

ideally, texdoc would append to TEXMFAUXTREES if it is already set (after all, people might want texdoc to find documentation in their auxtrees), but I would suggest waiting until a user requests it before bothering to implement that :).

As for realpath, I think it's fine to call realpath if it exists and just lose if it doesn't. Resolving symlinks is a pain.

It occurs to me (belated by many years) that since all the code to resolve symlinks is already in kpathsea (progname.c), it probably wouldn't be too hard to make a new program "kpserealpath" to do the job. But, at this poiint, I probably won't, unless a real need for it shows up. it doesn't seem worth it just for the absolute invocation of texdoc somehow ... --thanks, karl.

[wtsnjp]

It occurs to me (belated by many years) that since all the code to resolve symlinks is already in kpathsea (progname.c), it probably wouldn't be too hard to make a new program "kpserealpath" to do the job. But, at this poiint, I probably won't, unless a real need for it shows up. it doesn't seem worth it just for the absolute invocation of texdoc somehow

I see. For now, we use systems' realpath commands. So, platforms without the command will not be supported for this feature. If you make the new program kpserealpath for some reason in the future, I'm willing to switch to it.

Overall, when Texdoc which is not installed in the current TEXMFDIST is invoked, it automatically set temporal TEXMFAUXTREES and TEXMFDIST. This enables us to execute Texdoc without setting the PATH env variable (or whatever). Note that Texdoc also uses TEXMFHOME (for its configuration files) and TEXMFVAR (for a tlpdb cache), but users are responsible to set these variables to what they want to use. I will document this somewhere (perhaps in the README.)

$ texlua ~/repos/tug.org/Master/texmf-dist/scripts/texdoc/texdoc.tlu -dfiles,tlpdb -lM texlive-en
Info: Running Texdoc not installed in the current TEXMFMAIN.
texdoc debug-version: /Users/asakura/Develop/tug.org/Master/texmf-dist/scripts/texdoc/texdoclib.tlu v3.1
texdoc debug-files: Configuration files are:
texdoc debug-files: not found	/Users/asakura/Develop/tug.org/Master/texmf-dist/texdoc/texdoc-x86_64-darwin.cnf
texdoc debug-files: active	/Users/asakura/Develop/tug.org/Master/texmf-dist/texdoc/texdoc.cnf
texdoc debug-files: not found	/Users/asakura/Develop/tug.org/Master/texmf-dist/texdoc/texdoc-dist.cnf
texdoc debug-files: not found	/Users/asakura/Library/texlive/2019/texmf-var/texdoc/texdoc-x86_64-darwin.cnf
texdoc debug-files: not found	/Users/asakura/Library/texlive/2019/texmf-var/texdoc/texdoc.cnf
texdoc debug-files: not found	/Users/asakura/Library/texlive/2019/texmf-var/texdoc/texdoc-dist.cnf
texdoc debug-files: not found	/Users/asakura/Library/texmf/texdoc/texdoc-x86_64-darwin.cnf
texdoc debug-files: disabled	/Users/asakura/Library/texmf/texdoc/texdoc.cnf
texdoc debug-files: disabled	/Users/asakura/Library/texmf/texdoc/texdoc-dist.cnf
texdoc debug-files: not found	/Users/asakura/Develop/tug.org/Master/texmf-dist/texdoc/texdoc-x86_64-darwin.cnf
texdoc debug-files: disabled	/Users/asakura/Develop/tug.org/Master/texmf-dist/texdoc/texdoc.cnf
texdoc debug-files: not found	/Users/asakura/Develop/tug.org/Master/texmf-dist/texdoc/texdoc-dist.cnf
texdoc debug-tlpdb: Using cached data from /Users/asakura/Library/texlive/2019/texmf-var/texdoc/cache-tlpdb.lua
texlive-en	5.5	/Users/asakura/Develop/tug.org/Master/texmf-dist/doc/texlive/texlive-en/texlive-en.pdf
texlive-en	5.5	/Users/asakura/Develop/tug.org/Master/texmf-dist/doc/texlive/texlive-en/texlive-en.html
texlive-en	1.7	/Users/asakura/Develop/tug.org/Master/texmf-dist/doc/texlive/texlive-en/README
texlive-en	1.6	/Users/asakura/Develop/tug.org/Master/texmf-dist/doc/texlive/texlive-en/archive/changemail

In the case Texdoc set the TEXMF variables, the info message will always be shown in stderr. We cannot use a normal info message for it because this message should be shown before Texdoc set up its configuration from various sources.

[kberry]

All sounds good at this point. Thanks much for working on it.

[wtsnjp]

All done. The documentation for this feature goes to a wiki page.