<HTML><BODY style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; "><DIV><DIV>On 9 Jul 2007, at 4:13 am, Nikola Lecic wrote:</DIV><BLOCKQUOTE type="cite"><DIV><FONT class="Apple-style-span" color="#000000"><BR class="khtml-block-placeholder"></FONT></DIV><DIV>I'm not aware of a real one-command equivalent, outside of Mac of</DIV><DIV>course... (realpath(1) is just a ~25 lines implementation of</DIV><DIV>realpath(3), which is itself present on Mac OS X, right?). Anyway,</DIV><DIV>'cd -P' should work, i.e. something like</DIV><DIV><BR></DIV><DIV> #!/bin/sh</DIV><DIV> real_path()</DIV><DIV> {</DIV><DIV> current_path=`pwd` && relative_path=$1</DIV><DIV><BR></DIV><DIV> cd -P ${relative_path} # resolving symlinks and './..'s</DIV><DIV><BR></DIV><DIV> real_path=`pwd` && cd ${current_path}</DIV><DIV> echo ${real_path}</DIV><DIV> }</DIV><DIV><BR></DIV><DIV>should return the absolute path.</DIV></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV><DIV>OK, thanks.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><BLOCKQUOTE type="cite"><DIV>I'd like the installation process to honour symlinks since I wouldn't</DIV><DIV>like hardcoding of the path I temporarily use (passed to 'configure' by</DIV><DIV>kpsewhich).</DIV><DIV><BR></DIV><DIV>Actually, what would you do in this (imaginable) situation? Here are</DIV><DIV>some questions I included in the diff, could you please clarify these</DIV><DIV>things:</DIV><DIV><BR></DIV><DIV>(1) Does XeTeX hardcode TeX system elements paths provided/determined</DIV><DIV> during installation process? I'd say that it doesn't do so because</DIV><DIV> it works normally if I change the object of texlive symlink -- but</DIV><DIV> it's better to ask.</DIV></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV><DIV>I believe you're right, in general. All this stuff should work the same in xetex as in other kpse-based *tex binaries. I believe the build-time paths are compiled in, but will only be used as a last resort if no texmf.cnf is found via the usual kpathsearch process, based on the actual location of the binary. So it doesn't normally matter what the compile-time paths are, though it would seem tidier if they match a typical installation rather than some arbitrary build setup.</DIV><BR><BLOCKQUOTE type="cite"><DIV>(2) Does texhash's behaviour differ depending on whether the path it</DIV><DIV> uses respects symlinks?</DIV></BLOCKQUOTE><BLOCKQUOTE type="cite"><DIV><BR></DIV></BLOCKQUOTE><BLOCKQUOTE type="cite"><DIV>(3) Most importantly, can kpsewhich honour symlinks?</DIV></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV><DIV>I don't know.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>(Sorry, this is an area that I really don't know much about. I just follow what the rest of the teTeX/texlive world seems to be doing.)</DIV><BR><BLOCKQUOTE type="cite"><DIV><BR></DIV><DIV>If XeTeX doesn't hardcode TeX paths and relies on kpsewhich everywhere,</DIV><DIV>then maybe this whole thing is not needed.</DIV></BLOCKQUOTE></DIV><BR><DIV>It should rely on kpse functions, so I don't think the hardcoded paths really matter; but I do like the idea of making them more consistent and portable, to the extent that we can.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>I've been experimenting with your patches, and made just a few small changes based on what I've seen on OS X and Linux. I've now checked-in updated versions of the scripts, and hope these will work for you. (It seemed easier to go ahead and check these into SVN rather than swap patches back and forth.)</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Please let me know if I've broken anything in the changes I've made, and I'll be happy to make further adjustments.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Many thanks,</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>JK</DIV><DIV><BR class="khtml-block-placeholder"></DIV></BODY></HTML>