[OS X TeX] Re: PS on TeX Switcher

[Joachim Kock]

>There is however the following important problem. GUI programs don't
>get to use what happens in /etc/profile, since they don't get to see
>the shell. /etc/profile only kicks in when a shell is being used,
>namely in the Terminal. So all these changes to the PATH variable
>don't help programs like TeXShop and TextMate to determine where the
>correct TeX is to be found etc.

That's right, GUI programs don't automatically see the profile files.
But every process can define its own environment variables, and it
can take these variables from the profile files if it wants. This is
what Alpha does: read those files and set the PATH accordingly.  Then
all programs spawned by Alpha inherit that PATH, the same PATH as they
would have had if running in a shell.

This is a hack in the sense that if the user explicitly had set a PATH
in the environment.plist file, thinking that all GUI applications would
follow that, then he might be disappointed that Alpha ignores it by
simply overwriting the PATH with another one (for the scope of its own
process and all child processes).  One the other hand, this is what
all shells do: although the Terminal inherited a PATH from the Login
Window (the process that sets the PATH from the environment.plist file,
it seems), the first thing it does is to overwrite it with values
from initialisation files...

If in any case the application wants to set its own PATH (as many
frontends do with preference settings that thousands of users are now
setting manually), then it might as well happen manually.  But it is
altogether also tricky to adopt this philosophy that every application
should take care of itself and ignore the original inheritance
principles, of which the environment.plist mechanism is a logical
part.  Suppose for example that some text editor has the correct PATH
value, and calls a tex frontend.  Then by inheritance that frontend
will get the correct PATH again.  Execpt if it has an outdated PATH
written in some preference pane, and overwrites the PATH with that
value...  Or suppose you run your home-built ~/bin/xdvi and from
within it you invoke Alpha via the environment variable TEXEDIT.
Then Alpha sets the PATH according to profile files, and if the
home-built xdvi is not in that PATH, then when replying back to xdvi
a wrong copy will be launched...  (This problem is not specific to
reading profile files artificially; the problem is the same when
calling any editor that manually sets the PATH variable.)

In an sense I am sympathetic with the idea of setting PATH in
the environment.plist file.  I think it is the only logical
continuation of the unix tradition.  But then the shells should
respect it too, i.e., the initialisation files should not
overwrite the PATH but only add to it...  It is logical, because
the idea of setting the PATH in initialisation files is that
they are read by the outermost processes, the shells (hence the
name).  But that was the case in classical unix.  Now the
situation is different since there are GUI programs running
outside a shell.  So it is logical to move the PATH setting a
step up and have it in an environment.plist file read by the
login process.

The main opponent to the environment.plist mechanism is the
i-Installer who claims it can't work reliably if it inherits
a PATH it doesn't control.  I don't understand this argument.
If i-Installer wants to control the PATH, it should just set it
itself.  (This last sentence is not meant as an instruction,
but rather as an illustrationo of my lack of understanding.)

In short, I just wanted to point out you can read the profile
files if you want.  The rest is just a never-ending discussion.

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/