Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: putenv()/environ bug
- X-seq: zsh-workers 23721
- From: "Sean C. Farley" <scf@xxxxxxxxxxx>
- To: Andrey Borzenkov <arvidjaar@xxxxxxxxxx>
- Subject: Re: putenv()/environ bug
- Date: Sun, 29 Jul 2007 14:08:42 -0500 (CDT)
- Cc: zsh-workers@xxxxxxxxxx
- In-reply-to: <200707282246.16663.arvidjaar@xxxxxxxxxx>
- Mailing-list: contact zsh-workers-help@xxxxxxxxxx; run by ezmlm
- References: <20070725093254.T20275@xxxxxxxxxxxxxxx> <20070725215321.00e3b110.p.w.stephenson@xxxxxxxxxxxx> <20070725184302.S23862@xxxxxxxxxxxxxxx> <200707282246.16663.arvidjaar@xxxxxxxxxx>
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" <scf@xxxxxxxxxxx> 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@xxxxxxxxxxx
Messages sorted by:
Reverse Date,
Date,
Thread,
Author