Using environment variables without leaking memory?

David Daney ddaney at avtrex.com
Tue Oct 24 16:54:03 UTC 2006


Rob Landley wrote:
> 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? 

No I meant to call the system call execve() which knows nothing about 
$PATH and as far as I can see does is not influenced by the caller's 
environment in any way.

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

Basically you are saying you would like libc to take care of managing 
the environment in a manner that will not leak memory so that writing a 
new shell is easier.

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

Correct.

> Is this inherently broken and unworkable?

Assuming you are referring to the libc and not my idea, I have no idea. 
  My suggestion was just off the top of my head.  My suggestion is of 
course bug free :)

David Daney



More information about the uClibc mailing list