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

[Jérome Laurens]

I do not completely agree with you,
your interesting conclusions may not hold exactly as stated.
I did not understand whether your point was against the symlinks as a  
pollution or if it was really an intrinsic problem

Le 30 nov. 06 à 09:12, Joachim Kock a écrit :

> 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,

yes, this is a fact, but this is not a rule.
When pdftex will be available as a library, this assumption won't  
hold any longer.

> and they should embrace the PATH notion as faithfully
> as possible, instead of inventing another mechanism on their own.

(You meant the login shell PATH notion, not the general PATH notion)
Not really, this seems to contradict what you say below.
The frontends -can- embrace the login shell PATH if they want to.  
(see "correct it or not" below)
For example iTM2 uses the PATH and symlinks  mechanism to allow plug  
ins to add engines

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

Maybe...

>
> 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
>
> [..]

create a texshop engine with

echo $PATH
bash -l -c 'echo $PATH'
sh -l -c 'echo $PATH'
csh -l -c 'echo $PATH'
tcsh -l -c 'echo $PATH'

when run, in the console you would see all the PATHs

> [...]
> 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.

You assume that frontends and CLI must always behave the same tools
This is an arbitrary choice.
This is acceptable for the average user, but there exists the murphy  
law.

>
> 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).

But it actually works in iTeXMac2 if you put your tool in ~/Library/ 
TeX/bin, /Library/TeX/bin

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

See my /Library/TeX/ mail
If the PATH contains ~/Library/TeX/bin (or any other well defined  
location)
Then you will be able to say in the doc

"put you extra tools in ~/Library/TeX/bin
or /Library/TeX/bin if you are the administrator and want the tool  
available for all the users on your machine"

instead of

" choose a place where to put your extra TeX tool, or example ~/ 
Library/TeX/bin
find out what is you login shell,
find out how your login shell sets up its PATH,
edit the config file,
find out the syntax to add a component to the PATH,
save,
restart your frontend"

And I do not tell you about administrator privilege...
explanations about the PATH and so on

>
> 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.

Remember that the default shell has already changed once when  
upgrading Mac OS X
Relying too much on the PATH could have seriously damaged the  
application just because of a system upgrade
So this is not a design flow.

> 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.

It is clearly better for what it was designed for: the CLI
But PATH can be edited by other tools, even the user.
If things are broken, support can become a headache.

> 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?

No, this is not a workaround.
You forgot one point about the symlink.
When using the PATH, the directories will be searched in the same  
order whatever command you are looking for.
It is not possible for one specific command to bypass one directory.
This is no longer a problem when using symlinks.
symlinks are not sensitive to any change in the PATH,


> 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...

Not sure. One could also say

By choosing the PATH 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
PATH convention.

In a recent future, you may have (I hope)  a lite distribution that  
will not install system wide and will just allow people to try tex out.
If they are pleased, they will install the full distribution, if they  
are not they just trash everything.
No PATH pollution. No PATH solution.


Finally, your conclusion might be tempered:

IMO, the correct behaviour for a frontend might be to
- use the login PATH if the user has not unchecked some pref
- use the symlink if the user has not unchecked some pref

PATH exists, symlinks exist, none is better, none is worst, it depends.
So use both and every one would be happy


>
> 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/

------------------------- 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/