<div dir="ltr"><div>Hi Karl, all,<br></div><div><br></div><div>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).</div><div>Maybe a new option is needed to avoid breaking backwards compatibility?</div><div><br></div><div>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.</div><div>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.<br></div><div><br></div><div>That said, in my current work I bind to libkpathsea directly, where I have enough control to get the details right internally.</div><div>So I am not actually requesting any changes, as I won't be needing them myself. But it's a fun mini puzzle.<br></div><div><br></div><div>Greetings,<br></div><div>Deyan<br></div><div><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jul 2, 2024 at 6:10 PM Karl Berry <<a href="mailto:karl@freefriends.org">karl@freefriends.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Norbert (and Deyan and all),<br>
<br>
Maybe I look into kpsewhich and an options to output a different format<br>
where missing files are easily distinguished.<br>
<br>
I think you or I should add a couple of print statements so that in the<br>
case of multiple input files, the output is better. First idea:<br>
<br>
someinputfile.tex<tab>/some/location/someinputfile.tex<br>
nonesuch.tex<br>
<br>
Or in the case of -a, put all the results on the same line:<br>
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<br>
nonesuch.tex<br>
<br>
In any case, the idea is to make it simple to tell the result for each<br>
search. I clearly never thought about actual usage for the multiple<br>
input files case. The current output of reporting only the matches<br>
seems useless (it was just how it came out "by default" as I writing the<br>
program). Deyan, are you actually parsing the output from<br>
multiple-inputs?<br>
<br>
Although maybe for compatibility-safety the new format should only be<br>
enabled with an option, unfortunately.<br>
<br>
As for the output format: No TL filename will ever contain a tab, but I<br>
guess users' files might. Or a NUL byte. Maybe a --delimiter option<br>
(yuck). Or a more complex format where the results are on different<br>
lines, for complete generality, for isntance:<br>
<br>
someinputfile.tex<br>
->/some/location/someinputfile.tex<br>
nonesuch <br>
-><br>
<br>
Anyway, you get the idea. Let's just fix kpsewhich. Not hard.<br>
See the "/* Usual case: look up each given<br>
filename." loop at the end of kpsewhich.c.<br>
<br>
Overall, I expect updating the documentation, writing a test, etc., will<br>
be more work than tweaking the code :).<br>
<br>
<br>
Finally, another alternative: if it needs to work with old kpsewhich, it<br>
occurs to me (untested) that you could parse the --debug output. You<br>
could narrow the debug output with whatever option gives the result and<br>
as little else as possible. (I can research if need be.) -k<br>
</blockquote></div></div>