Zsh Mailing List Archive
Messages sorted by:
Re: putenv()/environ bug
- X-seq: zsh-workers 23704
- From: "Sean C. Farley" <scf@xxxxxxxxxxx>
- To: Peter Stephenson <p.w.stephenson@xxxxxxxxxxxx>
- Subject: Re: putenv()/environ bug
- Date: Wed, 25 Jul 2007 19:14:08 -0500 (CDT)
- Cc: zsh-workers@xxxxxxxxxx
- In-reply-to: <20070725215321.00e3b110.p.w.stephenson@xxxxxxxxxxxx>
- Mailing-list: contact zsh-workers-help@xxxxxxxxxx; run by ezmlm
- References: <20070725093254.T20275@xxxxxxxxxxxxxxx> <20070725215321.00e3b110.p.w.stephenson@xxxxxxxxxxxx>
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
BTW, is there a particular reason the standard *env() functions
cannot be used for all operations to environ if found?
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.
* 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
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. :)
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.
Unfortunately, this does not fix the problem. unsets are only affecting
the zsh environment but not environ. For example, here is a reduced set
of calls to duplicate it:
env | grep FOO
The call to env (/bin/env) will show "FOO=BAR" while the echo will not.
It is difficult to decide what to do. Here are some thoughts in my
1. Telling zsh that putenv() does not exist forces it to manipulate a
new copy of environ (zputenv() and createparamtable()). This almost
(see #2) prevents it from mixing *env() functions with direct changes
2. To truly prevent mixing, zsh may need to be told getenv() does not
exist. This way it is not directly (see #3) calling any *env()
functions. I have not seen a need (any bug reports) for this.
3. There may be other libc functions that call *env() functions. For
example, setlocale() calls getenv(). If all setlocale() calls are
done prior to any manipulation of environ, then this should be safe.
4. The FreeBSD *env() code can detect if environ != prevEnviron but not
if environ[x] has changed.
5. OpenSolaris does some similar stuff with its *env() functions.
Somebody may want to check if it is also affected.
6. The FreeBSD port should have a fix relatively soon to avoid this
by telling configure not to look for putenv().
Messages sorted by: