[tex-k] TL23 test failure, eptexdir/wcfname

Karl Berry karl at freefriends.org
Fri Mar 24 23:56:19 CET 2023

Hi Ken (and Takuji and all),

     I noticed in the copy that came back to me in the mailing lists
     that soem of the codepoints looked different (as if random 8-bit

Indeed. In my experience, it's not reliable to pass around lots of
arbitrary UTF-8, let alone non-UTF-8 (SJIS/EUC), in email. I usually
compress such things in binary attachments if it's important.

(Unfortunately the mail archives on tug.org are not UTF-8 friendly
either, something I hope to remedy in the not-impossibly-distant future,
but not for a while yet.)

     but the error appears to be that the files
     ending in '-tmp.tex' have not been created.

I don't know much about this test (except that it's complicated and
fragile :), but I think that the script web2c/tests/fn-generate.perl
(run from wcfname.test) generates a .tex file.  Then the .tex file is
run through eptex -ini --shell-escape to generate the -tmp file:

        $fnameT =~ s/\.tex$/-tmp.tex/;

And there various encoding conversions along the way.

So I suppose something in there is failing.

I'm impressed that Takuji was able to write such a complicated test
(dealing with UTF-8 conversions) to work on just about all systems.

I surmise that whatever is causing the failure on LFS is going to be
pretty impossible for anyone not on LFS to debug. Maybe have to run the
steps of the test by hand on LFS and non-LFS in parallel, to see what
happens differently and where.

The good news is that it's unlikely to make any practical difference if
the test passes or not. The functionality only matters (as I understand
it) to people using eptex with non-UTF-8 filenames/data. My hunch is
that number of such people on LFS is zero.


More information about the tex-k mailing list.