From: Jesse G. <je...@wi...> - 2004-08-15 11:19:12
|
Nicolas Cannasse wrote: >> 1.) drop support for the process environment, making this module entirely >> for dealing with a local copy/fabrication of the environment. >> >> 2.) Include support by way of two modules, one for the process >> environment, and one for the fabricated environment. >> >> 3.) Include support by way of one module with option arguments. None >> means >> use the existing process environment, Some x means use x. >> >> 4.) Something I haven't thought of... >> >> 1 is the cleanest, but useless if you want to interact with the existing >> process environment. 2 involves duplication of code. 3 is convenient, >> especially if the option argument is an optional argument defaulting to >> None, but it introduces that option software switch, so it's slightly >> less efficient, and more verbose then the existing implementation and >> 1 if you actually need to modify a local fabricated environment (Some x). >> >> What do you think? > > My vote is (1). Importing the current env into an hashtbl, modify it into > memory, then set it back. > However I'm interested in other people opinions. I think putenv actually causes memory leaks on some systems, like FreeBSD, so a blind mass commit might be a bad idea. What if we provided difference, intersect, and union functions of some sort? Commits to the process environment could then be performed intelligently. I need to write at least a difference function anyway for my own application... -- Jesse Guardiani, Systems Administrator WingNET Internet Services, P.O. Box 2605 // Cleveland, TN 37320-2605 423-559-LINK (v) 423-559-5145 (f) http://www.wingnet.net |