finding locations of many files via kpse

[Deyan Ginev]

Hi Karl, all,

Sounds like a good initiative. All it would take to preserve the order is
printing an extra character for those cases (be it newline, or tab, or
whatever combination is appropriate).
Maybe a new option is needed to avoid breaking backwards compatibility?

I know of at least one use case where the order is important - if some
custom conversion software called kpsewhich once with 10 filenames of
figures images, where say one of the filenames has been mistyped by the
author.
Not getting the resulting paths in the exact expected order could lead to
the wrong figure showing as a broken image in the HTML output.

That said, in my current work I bind to libkpathsea directly, where I have
enough control to get the details right internally.
So I am not actually requesting any changes, as I won't be needing them
myself. But it's a fun mini puzzle.

Greetings,
Deyan

On Tue, Jul 2, 2024 at 6:10 PM Karl Berry <karl at freefriends.org> wrote:

> Hi Norbert (and Deyan and all),
>
>     Maybe I look into kpsewhich and an options to output a different format
>     where missing files are easily distinguished.
>
> I think you or I should add a couple of print statements so that in the
> case of multiple input files, the output is better. First idea:
>
> someinputfile.tex<tab>/some/location/someinputfile.tex
> nonesuch.tex
>
> Or in the case of -a, put all the results on the same line:
>
> etex.src<tab>/u/texlive/karl/Master/texmf-dist/tex/luatex/hyph-utf8/etex.src<tab>/u/texlive/karl/Master/texmf-dist/tex/plain/etex/etex.src
> nonesuch.tex
>
> In any case, the idea is to make it simple to tell the result for each
> search.  I clearly never thought about actual usage for the multiple
> input files case.  The current output of reporting only the matches
> seems useless (it was just how it came out "by default" as I writing the
> program).  Deyan, are you actually parsing the output from
> multiple-inputs?
>
> Although maybe for compatibility-safety the new format should only be
> enabled with an option, unfortunately.
>
> As for the output format: No TL filename will ever contain a tab, but I
> guess users' files might. Or a NUL byte. Maybe a --delimiter option
> (yuck). Or a more complex format where the results are on different
> lines, for complete generality, for isntance:
>
> someinputfile.tex
> ->/some/location/someinputfile.tex
> nonesuch
> ->
>
> Anyway, you get the idea. Let's just fix kpsewhich. Not hard.
> See the "/* Usual case: look up each given
> filename." loop at the end of kpsewhich.c.
>
> Overall, I expect updating the documentation, writing a test, etc., will
> be more work than tweaking the code :).
>
>
> Finally, another alternative: if it needs to work with old kpsewhich, it
> occurs to me (untested) that you could parse the --debug output. You
> could narrow the debug output with whatever option gives the result and
> as little else as possible. (I can research if need be.) -k
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://tug.org/pipermail/texhax/attachments/20240702/5bf46159/attachment.htm>