[OS X TeX] Strange differences between paths in \include, \input and \includegraphics

[Peter Dyballa]

Am 14.03.2009 um 08:46 schrieb Ramón M. Figueroa-Centeno:

> Is this by design?

I think so.

> If so why?

Because it's completely handled by TeX – and TeX has no idea of file  
systems and the many file system syntaxes.

 From the TeX82 handbook ('texdoc -l tex' then choose on the from a  
number representing /usr/local/texlive/2008/texmf-doc/doc/english/ 
knuth/tex/tex.pdf):

376. The processing of \input involves the start_input subroutine,  
which will be declared later; the
processing of \endinput is trivial.
〈Put each of TEX’s primitives into the hash table 226 +≡
   primitive("input", input, 0);
   primitive("endinput", input, 1);

In §§ 511 and 537ff more details are revealed, including the problem  
with "spaced-out" file names. It's nowhere revealed which system  
calls in the end get used – their properties would explain the  
behaviour of \input.


> Is there a workaround?

If it does not work to use the absolute path (in UNIX it starts  
with /, in Classic Mac OS X it starts with <drive's name>:, in MS it  
starts with <capital letter>:), then it will work to provide  
(symbolic) file system links in the TeX source file's working  
directory which point to the files. And with "(symbolic) file system  
links" I mean links that in UNIX are created with the ln or link  
command (if the source file is on the same volume/slice/partition as  
the target link file, then you can create hard links; in the other  
case you have to use symbolic or sym-links by adding -s as an option  
to the ln or link command). The so-called links Finder offers on Mac  
OS are not useful because they're rather applications then real links.

Some recent MS Losedos version(s) is or are offering links too for  
POSIX compatibility.

--
Greetings

   Pete

Who the fsck is "General Failure," and why is he reading my disk?