[OS X TeX] Query the PATH [was: local vs. global symlink]

[Joachim Kock]

Haris wrote:

> In TextMate's LaTeX bundle, we'd rather not have to force the user to
> tell us what their preference is.  They have already stated their
> preference by setting the command line interface one way or another, and
> the editor should (IMHO) be smart enough to pick up that preference

I am happy you agree with me -- I was afraid nobody was listening.  I am
still convinced it is the most robust and correct solution.  The notion of
PATH already exists as a useful mechanism to find command line programs,
and it is not going away anytime soon.  The frontends are wrappers to a
command line program, and they should embrace the PATH notion as faithfully
as possible, instead of inventing another mechanism on their own.

Hopefully we can convince other frontends to query the login-shell PATH.

Let me spell out a few more details.

It is dead easy to query the login-shell PATH.  Assuming the login shell is
bash, just do

    bash -l -c 'echo $PATH'

(Mind the quotes: if you use double quotes instead of single quotes, the
variable PATH is expanded too early, and you get the callers PATH, not the
login-shell PATH.)
   
As an exercise, let's do it inside TeXShop: first write a file with this
content:

   %&pdflatex
   \documentclass{article}
   \begin{document}
   Test environment variables:
   \immediate\write18{ echo $PATH >> \jobname-tmp.tex }
   \input{\jobname-tmp}
   \immediate\write18{ rm \jobname-tmp.tex }
   \end{document}

and typeset it (making sure that you have shell-escapes enabled).  You will
see TeXShop's value of PATH.  (In fact it is rather the PATH it passes to
pdftex (this could be different)).

Now substitute the string "echo $PATH" with

   bash -l -c 'echo $PATH'

and typeset the document again to see the value of your login-shell PATH,
queried, not inherited, by TeXShop via pdftex.  Whether you see any
difference depends of course on your login-shell PATH.  Typically you will
see at least the difference that TeXShop (the first example) includes your
home directory in its PATH, which typically is not in your login-shell
PATH (the second example).

Of course, the frontend needs to do a little bit more, cf. what Alpha
does: before querying the shell, it is necessary to know which shell to
query: so first it reads the environment variable SHELL (which is
inherited), then query that shell.  Alpha has one short script for each of
the six common shells.  (You only query at startup, to mimic the classical
behaviour that environment variables are only inherited at launch -- if 
they change afterwards in the mother process, it will have no affect on 
the children.)



The question of having the same path in the frontend as in PATH, is not
only a question of the path to tex: the PATH contains other programs that
might be used from within tex, and which will work differently in frontend
and command line if they do not have the same PATH.

Consider the example above, but suppose you want to execute some shell
script myscr which outputs some text, instead of the simple command 
{bash -l -c 'echo $PATH'}.  If you do a little shell scripting from time 
to time, undoubtedly you have ~/bin in your PATH, and we assume that the 
shell script myscr is placed in ~/bin.  Now

  \immediate\write18{ myscr >> \jobname-tmp.tex }
  
will work fine in the Terminal (or in Alpha), since pdftex will inherit
the login-shell PATH, and hence be able to find myscr.  In contrast it will
not work in a typical frontend (say TeXShop).

This is not just a hypothetical example.  Recently on this list, Ross
explained a tex document which called a shell script to query
MathSciNet...

Interaction with Maple was also mentioned in that thread.  The command
line binary will typically be in /Applications/Maple 9.app/Contents/MacOS/bin/
and you are likely to have that in your PATH.  Again, calling maple from tex
will not work from within TeXShop (or most frontends).

Unless of course you specify the full path of the script or binary you
want to invoke, completely bypassing the whole PATH mechanism...


You may object that these examples are very exotic, but I think that's not
the point.  Look at it this way: whether it likes it or not, TeXShop has a
PATH. (I use TeXSHop as an example of a frontend here.)  Due to a design
flaw(?) in OSX, this PATH is not the login-shell PATH.  Now TeXShop can
choose whether it wants to correct this, or whether it will just accept the
primitive PATH it inherited.  The login-shell PATH is clearly better,
because it has been designed and adjusted to point to useful places.  In
particular, it contains tex since any tex installation procedure will have
to ensure this.  Now that TeXShop has chosen which PATH it wants, it can
ask the next question: rely on this good PATH or rely on some secondary
mechanism like a symlink convention, invented as a workaround for the bad
PATH problem?  By choosing the symlink solution, TeXShop reduces itself
from being a frontend to a generic tex installation to being a frontend to
a tex installed by MacTeX or those installers that adhere to some specific
symlink convention.  If the user installs from TUG or Fink, TeXShop would
not find tex without special configuration.  By choosing the login-shell-PATH
solution, compatibility is guaranteed with any imaginable working tex 
installation, in a rather future-proof way...

Cheers,
Joachim.

------------------------- Info --------------------------
Mac-TeX Website: http://www.esm.psu.edu/mac-tex/
          & FAQ: http://latex.yauh.de/faq/
TeX FAQ: http://www.tex.ac.uk/faq
List Archive: http://tug.org/pipermail/macostex-archives/