[tex-live] Kpathsea in TL2007

[Heiko Oberdiek]

On Sat, Feb 17, 2007 at 06:21:40PM +0100, Zdenek Wagner wrote:

> 2007/2/17, Heiko Oberdiek <oberdiek at uni-freiburg.de>:
> >On Sat, Feb 17, 2007 at 05:19:53PM +0100, Zdenek Wagner wrote:
> >
> >> 2007/2/17, Heiko Oberdiek <oberdiek at uni-freiburg.de>:
> >> >On Sat, Feb 17, 2007 at 10:09:57AM +0000, Philip & Le Khanh wrote:
> >> >
> >> >> Akira Kakuto wrote:
> >> >> >
> >> >> >I forgot to write about a small difference between
> >> >> >Windows and other systems concerning the order of
> >> >> >file search.
> >> >> >
> >> >> >[1] Windows
> >> >> >    (a) \input foo
> >> >> >        try foo.tex first, if not found then try foo
> >> >> >
> >> >> >[2] Other systems
> >> >>
> >> >> >    (c) \input foo.bar
> >> >> >        try foo.bar.tex first, if not found then try foo.bar
> >> >>
> >> >> The behaviour as described for Windows seems logical (indeed,
> >> >> required) to me : imagine one has
> >> >>
> >> >>       \input letter-spacing.sty
> >> >>
> >> >> then surely one would want letter-spacing.sty to be
> >> >> loaded, and not letter-spacing.sty.tex, even if the
> >> >> latter existed.
> >> >
> >> >But (a) prevents that "foo" can be loaded if
> >> >both "foo" and "foo.tex" exist. :-(
> >> >
> >> >Therefore I prefer a new \input primitive that uses
> >> >curly braces (such as \pdfximage) without default
> >> >extension. Then it would be possible to reliable
> >> >address each file name (including spaces, quotes, ...)
> >> >
> >> It is not a good idea because \input{foo} is a LaTeX macro and assumes
> >> to load foo.tex if it exists. It can make things confusing.
> >
> >No, it isn't, I said a *new* primitive, of course with a new name, e.g.
> >\inputfile, \pdfinput, ... or whatever name.
> >Also the existence of this new primitive can be tested in a reliable way.
> >Thus the compatibiliy isn't violated and new macro code can use
> >the new primitives. It reduces confusion because nobody must
> >guess which file names can be detected and which files are loaded.
> >(Also new primitives for \openin/\openout are needed.)
> >
> OK. I think that there are already  extensions in some distributions
> mainly for handling file names with spaces. 

It just increases the confusion:
* There is no reliable way for asking whether this feature is available
  or not.
* It just shifts the problem from spaces to quotes.

Now you cannot use spaces *and* quotes.

> New set of primitives with
> new names will provide portable solution.

Yes.

Yours sincerely
  Heiko <oberdiek at uni-freiburg.de>