Helmut Kopka's interpretation of the TDS

[Sebastian Rahtz]

 > However: Unix filesystems are most of the time long trees, while
 > PC filesystems are most of the time made of many short trees
 > under the root of each disk. That's a fact of reality.
I really dont know where you get this view. I dont see it at all
in the Unix and PC systems that I watch
..
 > habit, and my analysis of this difference is: this is mainly
 > because of the existence of "ln" in Unix, and its absence in DOS.
and I dont  see this either. i dont think i use "ln" anywhere in my
TeX setup

 > personal installation. But when writing a generic software,
 > supposed to be usable on different machines on which you have no
 > control, it is best, in my opinion, to write it so as not to
 > violate the habits. Otherwise the software is more fragile - i.e.
there are habits; there are local conventions; and there are
international conventions. can you supply *any* evidence that there is
an international convention there PC trees and short and Unix ones are
long? Does Microsoft recommend this?

 > So, the result of switching to TDS would have been: much less
 > tested software, hundreds of pages of docs becoming suddenly
 > inaccurate, longer directories leading to more fragile
 > installations. As I am not an irreducible fan of TDS with the
hey, who is forcing you? but the way I look at it is that your people
will have to work increasingly hard in the future if new distributions
of fonts and macros start to appear which assume TDS layout. You'll
have to supply "TDS to flat" conversion tools. thats up to you.

 > the rule of thumb is : the shortest, the safest. TDS makes some
 > pathes much longer than emTeX, especially for fonts.
the TDS does say, clearly, that if you dont use recursive file
searching, you are in a mess. if you do use it, the depth of the tree
is not relevant to the size of variables

 > users). You forget also that recursive search makes things often
 > much slowwwwwer. 
if badly implemented, true.

 > BTW, is somebody planning to port TeX from C to Java, for
 > complete independence from platforms and to have only one set of
yes, Tim Murphy is looking at it

 > the tree. So, for each platform, each implementor has just to
 > write an "index" to put files in his own tree, i.e. a script
 > consisting of instructions "copy files in TDS tree into their
 > corresponding place in the tree specific to the implementation". 
sure, why not. use the TDS as a mental model, and as a transmission
format, and provide a conversion. sounds fine by me. so long as we
*talk* TDS, who cares how the OS implements it? what i want is to be
able to say to someone "put hyperref.sty in tex/latex/hyperref"; if
you choose to interpret that as an instruction to kick some process
which translates it to c:\texinputs, then thats fine by me.

I am not sure what you are saying, really. The bottom line seems to be
that the TeX implementation you choose to work with has an inefficient
implementation of recursive path searching, so you need to provide a
layer of efficiency for your users. I don't see any more than this.

I'll carry on with my users here running emTeX off a network drive,
with the support tree entirely TDS, and all the paths and so on set by
the shell they use (WinEDT or Eddi4TeX). A few small environment variables,
emTeX as the base engine, stable, fast enough - and most importantly
just the same as my parallel Unix setup. I dont spend much time in
DOS, so I dont/cant do any complicated hacks, and I don't do much
maintenance on it. It just works.

Sebastian