From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12533 invoked from network); 13 Apr 2000 17:55:04 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 13 Apr 2000 17:55:04 -0000 Received: (qmail 3080 invoked by alias); 13 Apr 2000 17:54:51 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 10743 Received: (qmail 3071 invoked from network); 13 Apr 2000 17:54:50 -0000 Date: Thu, 13 Apr 2000 18:54:19 +0100 From: Peter Stephenson Subject: PATCH: Re: PATCH: local exports In-reply-to: "Your message of Thu, 13 Apr 2000 15:42:36 -0000." <1000413154237.ZM16996@candle.brasslantern.com> To: zsh-workers@sunsite.auc.dk (Zsh hackers list) Message-id: <0FSY00HFQV2JPE@la-la.cambridgesiliconradio.com> Content-transfer-encoding: 7BIT Bart Schaefer wrote: > The following seems to be a pretty effective test: > > unenv() { > local x > x=($(typeset +x)) > local $x > unset $x > /usr/bin/printenv # $path is (correctly?) nuked by unset PATH > } > > The output on my system differs if I run this function twice. The first > time it is: > > TERM=xterm > HOME=/home/schaefer > _=/usr/bin/printenv > COLUMNS=80 > LINES=24 Oddly, this wasn't actually my fault; it came from the import of special parameters at startup. The code set the variable, then tried to replace the value in the environment with the value generated internlly, for consistency. Unfortunately it was trying to replace it into the old environment, which failed. This returned null, which was set to the env element of the parameter struct. Hence when the new code looked for this to see if the value was in the environment already it failed, so never deleted it. (It was doing this on the `local', not the unset, since the local parameter wasn't being exported.) This usually didn't show up because the values in the environment were OK anyway, as in this case, so the fact that they didn't get replaced didn't matter. > } This was necessary to get around the -g-with--x kludge. Ksh 88 doesn't > } have that and its `typeset -x' behaves more or less like `typeset +g -x'. > > This is why I keep talking about ksh emulation. I want to be able to > keep exporting things from functions with `typeset -x' the way I have > for the entire time I've been using zsh, but it causes problems when > running scripts written for ksh. OK, so it's a ksh compatibility vs. old zsh compatibility issue. The problem with using an option is that in this case the latter is the kludge, but needs to be enabled by default. There isn't a good way round that. If somebody wants to write an option they can. It could be called e.g. GLOBAL_EXPORT and be on by default; at least that tells you that something's up. Index: Src/params.c =================================================================== RCS file: /cvsroot/zsh/zsh/Src/params.c,v retrieving revision 1.4 diff -u -r1.4 params.c --- Src/params.c 2000/04/13 14:22:47 1.4 +++ Src/params.c 2000/04/13 17:51:26 @@ -454,6 +454,7 @@ { Param ip, pm; char **new_environ, **envp, **envp2, **sigptr, **t; + char **old_environ = environ; char buf[50], *str, *iname; int num_env, oae = opts[ALLEXPORT]; #ifdef HAVE_UNAME @@ -516,9 +517,12 @@ pm->flags |= PM_EXPORTED; pm->env = *envp++ = ztrdup(*envp2); *envp = NULL; - if (pm->flags & PM_SPECIAL) + if (pm->flags & PM_SPECIAL) { + environ = new_environ; pm->env = replenv(pm->env, getsparam(pm->nam), pm->flags); + environ = old_environ; + } } } *str = '='; -- Peter Stephenson Cambridge Silicon Radio, Unit 300, Science Park, Milton Road, Cambridge, CB4 0XL, UK Tel: +44 (0)1223 392070