From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20644 invoked from network); 29 Jul 2007 19:09:08 -0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.2.1 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by ns1.primenet.com.au with SMTP; 29 Jul 2007 19:09:08 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 36011 invoked from network); 29 Jul 2007 19:09:02 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 29 Jul 2007 19:09:02 -0000 Received: (qmail 22796 invoked by alias); 29 Jul 2007 19:08:57 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 23721 Received: (qmail 22779 invoked from network); 29 Jul 2007 19:08:56 -0000 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by sunsite.dk with SMTP; 29 Jul 2007 19:08:56 -0000 Received: (qmail 35634 invoked from network); 29 Jul 2007 19:08:55 -0000 Received: from farley.org (HELO mail.farley.org) (67.64.95.201) by a.mx.sunsite.dk with SMTP; 29 Jul 2007 19:08:51 -0000 Received: from thor.farley.org (thor.farley.org [192.168.1.5]) by mail.farley.org (8.14.1/8.14.1) with ESMTP id l6TJ8gRC022243; Sun, 29 Jul 2007 14:08:43 -0500 (CDT) (envelope-from scf@FreeBSD.org) Date: Sun, 29 Jul 2007 14:08:42 -0500 (CDT) From: "Sean C. Farley" To: Andrey Borzenkov cc: zsh-workers@sunsite.dk Subject: Re: putenv()/environ bug In-Reply-To: <200707282246.16663.arvidjaar@newmail.ru> Message-ID: <20070729140248.D2588@thor.farley.org> References: <20070725093254.T20275@thor.farley.org> <20070725215321.00e3b110.p.w.stephenson@ntlworld.com> <20070725184302.S23862@thor.farley.org> <200707282246.16663.arvidjaar@newmail.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed On Sat, 28 Jul 2007, Andrey Borzenkov wrote: > 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. OK. That would be old. I cannot think of any relatively current system that does not have unsetenv(). >>> 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. Well, the comment comes after the use of zputenv(). The block of code under the comment does not use *putenv(). >>> 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. That would work for me. If anyone would like me to test any patches, I will. Sean -- scf@FreeBSD.org