Re: [MACTCL] Setting environment vars from tcl

[James B. <jk...@mr...>]

On Fri, Mar 01, 2002 at 11:03:37AM -0800, Jim Ingham wrote:
> Something else must be going on here.  I wrote this simple program:
> 
> #include <unistd.h>
> 
> int main (int argc, char **argv, char **envp)
> {
> 
>    char * elem;
> 
>    for (elem = *envp; elem != NULL; (elem = *(++envp))) {
>      printf ("%s\n", elem);
>    }
> }
> 
> compiled it as /tmp/envprint

I can repeat this experiment and it works for me too, so it's clearly just
something odd with zsh. So this isn't a tcl issue and we can ignore it :-)

> Right, dyld doesn't reread the environment every time it goes to do a 
> load.  It reads it once at startup and then uses the cached copy.  So 
> this is perhaps a dyld bug (but dyld does do some work on the path, and 
> library loading needs to be pretty fast so maybe not).  But it is not a 
> Tcl bug.

Indeed - I've now downloaded the source (thanks for the pointers to those) and 
can see what you mean. It would be useful if there was a function to
reinitialise the cached dyld_library_path (and co.) variables, but there
isn't. For now I've worked around this with an ultra-hacky second program
which sets the environment variable, forks and execs, leaving the parent to
exit naturally (to avoid an extra dock icon). This seems unnecessarily
complex, but it does at least work.

How do system apps get around this? Do they simply assume that their libraries 
are going to be in the default search path? What about other apps? Do people
normally require the user to manually set the DYLD_LIBRARY_PATH before running 
the applications? I guess it's only normally a problem if you're loading with
explicit dyld calls rather than letting the runtime linker do the stuff for
you, so most programs never have to worry about such things.

> with your own environment is not an everyday task, gets done first.  Not 
> a great answer, but Apple has limited resources, we aren't MS after all, 
> so some things come more slowly...

Well I for one are pleased that Apple isn't MS! You've been a great help in
pointing the way forward. Cheers.

James

-- 
James Bonfield (jk...@mr...)   Fax: (+44) 01223 213556
Medical Research Council - Laboratory of Molecular Biology,
Hills Road, Cambridge, CB2 2QH, England.
Also see Staden Package WWW site at http://www.mrc-lmb.cam.ac.uk/pubseq/