TEXMFHOME on Windows (for users with long names, diacritics or spaces in their names)

[John Collins]

Hi Denis,

Was the problem your student saw confined to how kpsewhich displayed the value 
of TEXMFHOME?  Or was there also a problem when she tried running a program 
like pdflatex, a problem such as pdflatex not finding files that are under 
TEXMFHOME?

I ask because I tried this myself in the following way:

1. I created a directory with a non-ASCII character in it, and changed 
TEXMFHOME to add that directory to the search path.

2. Just as your student found, kpsewhich displayed a strange value for the 
non-ASCII character.

3. I then put a file 'uuuu.tex' in the tex/latex subdirectory in the new TEXMF 
tree.

4. When I ran 'kpsewhich uuuu.tex', it reported successfully finding the file, 
but with the apparently wrong name for the directory.

5. I used pdflatex to compile a .tex file that had the line  \input{uuuu} in 
it.  The file uuuu.tex was correctly read, and pdflatex reported the correct 
directory name.

Further tests showed that kpsewhich appears to be coding its output in the 
system code page, which on my system (and probably a default Windows system in 
France) is CP1252.  Simply doing 'chcp 1252' resulted in a correct display from 
kpsewhich.

So I think the problem is a bug only in how kpsewhich displays its output.  My 
tests are on Windows 11 with an up-to-date TeX Live 2024.

John



On 5/24/24 4:48 PM, Denis Bitouzé wrote:
> Hi Siep,
> 
> Le 24/05/24 à 21h57, Siep Kroonenberg via tex-live a écrit :
> 
>> I have spent considerable time on how to handle non-ascii directory
>> paths under Windows.
> 
> Thanks for that!
> 
>> Maybe the principal problem is that the default 'codepage' of the
>> command-prompt is non-ascii.
> 
> Couldn't Powershell be useful here?
> 
>> And if a script sets the codepage to utf-8, then this setting will NOT
>> be inherited by child processes.  And it requires administrative
>> permissions to set the default codepage to utf-8.
> 
> I see (almost ;)
> 
>> https://tug.org/texlive/windows.html#nonascii contains a few not
>> quite satisfactory workarounds.
> 
> OK, good to know.
> 
>> Sorry.
> 
> You're very welcome: many thanks for the hard work already done!