On Thursday 26 July 2007, Sean C. Farley wrote: > On Wed, 25 Jul 2007, Peter Stephenson wrote: > > On Wed, 25 Jul 2007 10:09:22 -0500 (CDT) > > > > "Sean C. Farley" wrote: > >> As noticed here following a change in FreeBSD's *env() functions, zsh > >> is mixing *env() (putenv() in this case) functions with direct access > >> to the environ variable's contents against the IEEE Std 1003.1 > >> specification. > >> > >> BTW, is there a particular reason the standard *env() functions > >> cannot be used for all operations to environ if found? > > The code in question is quite old and I believe it predates (un-)setenv. And you simply did not have any way to *unset* environment string in some systems; I think (un-)setenv is BSD extension. > > There's a long history of fiddling with these for problems on various > > systems, so I'm a little unwilling to change it without some guidance. > > > > For example, > > > > /* > > * Under Cygwin we must use putenv() to maintain consistency. > > * Unfortunately, current version (1.1.2) copies argument and may > > * silently reuse existing environment string. This tries to > > * check for both cases > > */ > > I understand. > > > This is a little confusing since the code in question (addenv in > > params.c) doesn't actually use putenv(). > > Legacy comments are only meant to throw developers off the track. :) > Huh? addenv() is using zputenv() that is using putenv() where avaialable. Now it may be legacy in the sense Cygwin implemenation has changed; but unfortunately I use Cygwin no more nor have environment to check it. > > Given we manipulate environ quite a lot anyway, is there any harm in > > using only the zsh versions of zgetenv() and zputenv()? There's a > > getenv() instead of a zgetenv() in init.c: I think that was just a > > typo by me. > > *code snipped* > > Unfortunately, this does not fix the problem. unsets are only affecting > the zsh environment but not environ. What about - check if (un-)setenv is available and use them. On legacy systems use existing implementation. This probably will mean we will be using native utilities everywhere on modern systems. -andrey