[tex-k] kpsewhich/kpathsea and $HOME

[Gerben Wierda]

Hello,

I had a bug report by someone who used my installer to install teTeX on 
Mac OS X. The problem was that the installer hung completely (never 
finished) or so it seemed as he waited for hours on end.

I had one earlier problem with my installer (which I fixed) which was 
because of tcsh alias settings influencing my scripts. So I asked this 
user to send me his environment and his aliases.

Nothing really strange, with the exception of his HOME environment 
variable, which ended on a '/' (he had set this himself somewhere in 
Apple's system). When he changed that into something without a '/' on 
the end, the installer ran fine.

I asked him to reproduce again. So he reset his HOME and re-ran the 
installer. Then, when it had hung for an hour or so, he sent me the 
output of 'ps laxww' with about 1.5 hours in between.

     0  2081  2079   0  31  0     1732    660 -      S     ??    0:00.08 
sh /Volumes/teTeXvolume/TeXGSInstaller.app/Contents/Resources/installdmg 
Letter Paper Size Remove Old SymLinks Install and initialize TeX
     0  2123  2081   0  31  0     1988    868 -      S     ??    0:00.14 
sh /usr/local/teTeX/bin/powerpc-apple-darwin1.3.7/texconfig init
     0  2135  2123   0  14  0     4992   4060 -      R     ??    0:04.71 
kpsewhich

2081 is my installer script, which runs
2123 texconfig init, which runs
2135 kpsewhich

kpsewhich is *not* hanging, 1.5 hours later there is a different 
kpsewhich running.

I tested this on my own system, and indeed, if I have my HOME set to 
/Users/gerben, everything goes smooth. But if I have my HOME set to 
/Users/gerben/, it all becomes extremely slow, both the kpsewhich 
commands in the scripts (texconfig, fmtutil) as well as the actual 
commands like "tex -ini -fmt=tex -progname=tex tex.ini". He must have a 
slow system or maybe a bg private texmf tree, because the difference 
here is
HOME=/Users/gerben	time for texconfig init = 21sec
HOME=/Users/gerben/	time for texconfig init = 35min

A bit more debugging and a look at texmf.cnf and the explanation 
provides the answer: A double slash in a variable for kpathsea means 
that all subdirectories are searched. So this is known kpathsea 
behaviour and not a bug.

Now, that means we have two types of semantics for //. In unix directory 
terms it means "ignore any extra /". In kpathsea terms it means "search 
all subdirectories". That would be no problem if every part of kpathsea 
is 'internal', that is, there is no overlap with the directory system. 
But there is, namely $HOME.

There are two solutions I can see for this possible though unprobable 
mix up
1. Use a different syntax in kpathsea for 'expand all subdirectories', 
for instance /.../ instead of //. That would of course mean that 
existing texmf.cnf's will have to be changed and a change like that will 
give problems. I think it is a cleaner option because of the removal of 
the 'different semantics' issue alltogether.
2. When reading the HOME environment variable, make sure it does not 
have a trailing slash as this is 'valid' in Unix, but has undesired or 
at least unexpected results in kpathsea.

Gerben