Re: setenv, unsetenv (Was Re: Re: EXT:GETENV Re: [cmucl-commit] CMUCL commit: src/code (save.lisp))
* Raymond Toy <4AD71250.90204@stericsson.com> : Wrote on Thu, 15 Oct 2009 08:15:12 -0400: | Note that Solaris 8 (yes, it's ancient) does not have unsetenv and | setenv, so if we do this, can we try to just use putenv? I guess that | precludes us from removing something from the environment. If you cannot remove anything from the environment, I imagine you could just conditionalize out the unsetenv call branch without loss, maybe set it the value to "". There are no current callers anyway. | Solaris 10 does have unsetenv and setenv, though. | | And I think it is important to keep *environment-list* synchronized. | Either that or change load-foreign, execve, run-program and others | that use *environment-list* to set the environment. The idea behind what I suggested was to have minimal impact on existing code --- so the *environment-list* would continue to be used as before by these functions; it would continue to reflect the unix environment list at startup and have all changes made by the user via SETENV and (SETF GETENV). -- Madhu
Madhu wrote:
* Raymond Toy <4AD71250.90204@stericsson.com> : Wrote on Thu, 15 Oct 2009 08:15:12 -0400:
| Note that Solaris 8 (yes, it's ancient) does not have unsetenv and | setenv, so if we do this, can we try to just use putenv? I guess that | precludes us from removing something from the environment.
If you cannot remove anything from the environment, I imagine you could just conditionalize out the unsetenv call branch without loss, maybe set it the value to "". There are no current callers anyway.
It would be nice if Solaris 10 could do this. I guess we could have a different version for Solaris which would catch the undefined function error and do the right thing. Doesn't need to be done now.
| Solaris 10 does have unsetenv and setenv, though. | | And I think it is important to keep *environment-list* synchronized. | Either that or change load-foreign, execve, run-program and others | that use *environment-list* to set the environment.
The idea behind what I suggested was to have minimal impact on existing code --- so the *environment-list* would continue to be used as before by these functions; it would continue to reflect the unix environment list at startup and have all changes made by the user via SETENV and (SETF GETENV).
Yes, I agree with this approach. Ray
OK, I'm confused again. Why do we want to switch to libc versions of getenv and setenv? What's the problem with the current *environment-list* approach? Mike McDonald mikemac@mikemac.com
participants (3)
-
Madhu -
Mike McDonald -
Raymond Toy