Using environment variables without leaking memory?

[Rob Landley]

On Monday 23 October 2006 5:09 pm, David Daney wrote:

> > other than by you just now).  But right now I'm writing a shell and this 
can 
> > set and reset the same environment variables multiple times (for loops, 
etc).  
...
> How about not modify your environment at all.  I think the only time it 
> is important is if you are going to exec().

Except for the part where execvp looks at $PATH in a library function that's 
using getenv() behind the scenes, you mean?  Or the way the "cd" command 
(which can't fork or it won't work) looks at $PWD if it has no argument?  
Distinguishing between local variables and exported variables becomes much 
more of a pain if you defer the exporting, and various things that just do 
getenv() right now could no longer be called from shell context (or would 
have to be made aware of the shell's non-system way of reinventing the wheel, 
whereas right now I can just do a getenv() before setting a variable and if 
it exists it's global, although I haven't implemented
"PATH=blah:$PATH ./thingy" yet and expect that will require careful sequencing 
but that _is_ an implicit post-fork export, but still pre-execvp)...

> If that is the case, just  
> use execve() and pass the exact environment you need, and explicitly 
> manage your memory however you see fit.

So your suggestion for modifying the environment is "don't"?  Is this 
inherently broken and unworkable?

> David Daney

Rob
-- 
"Perfection is reached, not when there is no longer anything to add, but
when there is no longer anything to take away." - Antoine de Saint-Exupery