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