Re: [MACTCL] Setting environment vars from tcl

[Jim I. <ji...@ap...>]

On Friday, March 1, 2002, at 10:11  AM, James Bonfield wrote:

> OK, in a follow up to my own findings, I now see that there's still a 
> few
> other tcl problems (and perhaps system problems) involving environment
> variables.
>
> The first is that exec seems to clear all of them. Eg try "exec zsh" 
> and then
> printenv. I can get this to work in a test C application using 
> NSGetEnviron
> and execl, so it looks like it's a tcl specific bug.

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

then did:

inghji:/tmp > tclsh
% exec /tmp/envprint
HOME=/Network/Servers/cauchy/homes/thorin/jingham
SHELL=/bin/tcsh
USER=jingham
% parray env
env(HOME)                    = 
/Network/Servers/cauchy/homes/thorin/jingham
env(SHELL)                   = /bin/tcsh
env(USER)                    = jingham
% set env(FOO) BAR
BAR
% set env(FOO) BAR
BAR
% parray env
env(FOO)                     = BAR
env(HOME)                    = 
/Network/Servers/cauchy/homes/thorin/jingham
env(SHELL)                   = /bin/tcsh
env(USER)                    = jingham
% exec /tmp/envprint
HOME=/Network/Servers/cauchy/homes/thorin/jingham
SHELL=/bin/tcsh
USER=jingham
FOO=BAR
% exit

This is before your applying your patch, which is why I had to set it 
twice...  I also trimmed the output of the env commands for clarity.  
But this worked fine.  Maybe something in zsh is clearing the 
environment????  Not sure here.

>
> The second is that although setting environment variables does appear 
> to work
> correctly changing the value of DYLD_LIBRARY_PATH appears to have no
> effect. I've tried changing PATH by using "exec prog", set env(PATH), 
> and then
> exec prog once more. This demonstrates that the environment really is 
> being
> set correctly. However I can't get "load" to work by changing
> DYLD_LIBRARY_PATH within wish.
>
> If I change it outside of wish (in zsh say) then load within subsequent 
> wishes
> works fine (thus demonstrating that the recent patch to fix this works 
> fine -
> cheers). I can't see any mention of DYLD_LIBRARY_PATH in tcl, so does 
> this
> imply that the NSAddImage function uses a copy of DYLD_LIBRARY_PATH 
> inherited
> at application startup and not the copy found in the current environment
> variable?
>


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.

If you really really care about this sort of thing, the dyld source is 
part of the Darwin sources - in the cctools project.  So you could go 
get it from opensource.apple.com and confirm this yourself.  But I just 
looked and it does just what you suspected...


> I'm not sure how much further I can go with my changes to this code as 
> I'm a
> complete Mac newbie really. I'm still finding it virtually impossible to
> find documentation. Anyone know where _NSGetEnviron is documented? I 
> did a
> systemwide grep and failed to find it. Google finds little else other 
> than the
> tcl source itself. Come on Apple! Either gives us docs or the source 
> for the
> libraries themselves. Please?

In this case, the source libraries ARE part of the Darwin repository.  
_NSGetEnviron is in crt_externs.c in the Libc project on 
opensource.apple.com, though it is a bunch of gnarly macros.  You will 
have to do more detective work than I have time for right now to figure 
out what it really means.  Remember, ALL the Kernel and BSD level stuff 
and most of Core Foundation is available in source form.

On the Docs side, the Developer docs team is working their little tails 
off but there is a lot to do.  NeXT badly neglected all the BSD 
manpages, so they all have to be fixed, the AppKit & Carbon folks are 
busily adding stuff to their API's, etc, etc...  So they have to 
prioritize, and stuff that is more common, and you must admit mucking 
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...

>
> (This is no reflection on you Jim - you've done a stirling job and I 
> thank
> both you and Apple for allowing you the time and resources. Thanks.)
>

No prob, it is frustrating at times, I know.

Jim
--
Jim Ingham                                   ji...@ap...
Developer Tools - gdb
Apple Computer