Re: GNUstep runtime & putenv()

[Richard Frith-Macdonald]

On Thursday, January 11, 2001, at 12:28 PM, ian.mondragon@bankofamerica.com 
wrote:

> **NOTE: i sent this message earlier from another account, but it doesn't 
> seem to have been delivered.  if this is a duplicate, please disregard it. 
> :-) 
>  
> all- 
>  
> in the past couple of days i have been designing a tool that populates a 
> user's environment via the GNUstepDefaults as opposed to the traditional 
> .profile & shell .rc files, which i am calling "gshell".  while the code is 
> ~80% in place, i have come to realize that the GNUstep objc runtime caches 
> the user environment & restores it to it's original state upon 
> app/tool/whatever completion, according to the laws of NSProccessInfo - i 
> have verified this by calling another (straight c) program during execution 
> & witnessing my work doing exactly what it supposed to do (namely, working), 
> only to have the environment reset afterwards. 
>  
> can anyone give me a pointer (har, har) on how to work around this and have 
> setenv() and putenv() populate the *real* environment instead of the cached 
> one? 

I'm not actually sure what you are trying to achieve, or what the problem is.

1. GNUstep doesn't reset/change the environment.
2. NSProcessInfo *does* cache the environment ... it reads the environment on
startup, and any accesses made to the -environment method will return the
dictionary returned on startup.

To have changes made by putenv effect the -environment method, you would need
to write a category that overrides -environment to build and return a new
dictionary every time it's called.

If you want to manipulate the environment of a subprocess, you simply use the
setEnvironment: method of NSTask before launching the task.

Presumably you are running '/bin/sh -i' as the task.

Actually, a nasty suspicion occurs to me.  You do know that it's impossible
for a process to set the environment for a subsequent (rather than a child)
process don't you?