[OS X TeX] Strange differences between paths in \include, \input and \includegraphics
Peter_Dyballa at Web.DE
Sat Mar 14 07:06:45 EDT 2009
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/
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
Who the fsck is "General Failure," and why is he reading my disk?
More information about the MacOSX-TeX