From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1147 invoked from network); 5 Feb 2000 22:04:42 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 5 Feb 2000 22:04:42 -0000 Received: (qmail 2525 invoked by alias); 5 Feb 2000 22:04:36 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 9582 Received: (qmail 2514 invoked from network); 5 Feb 2000 22:04:35 -0000 To: Christophe Kalt , zsh-workers@sunsite.auc.dk Subject: Re: LC_CTYPE weirdness In-reply-to: ""Bart Schaefer""'s message of "Thu, 03 Feb 2000 18:41:02 GMT." <1000203184102.ZM7939@candle.brasslantern.com> Date: Sat, 05 Feb 2000 22:07:42 +0000 From: Peter Stephenson Message-Id: "Bart Schaefer" wrote: > On Feb 1, 11:21am, Christophe Kalt wrote: > } i have a line "export LC_CTYPE=iso_8859_1" in one of my startup > } files, and it used to work fine. I recently got a new laptop, > } and went on to install the same OS, but while reinstalling > } packages, i ended up upgrading zsh from 3.0.5 to 3.0.7. > } > } anyhow, for some reason, LC_CTYPE doesn't seem to get > } exported, yet it is set (as a variable). > > The problem is that all the LC_* parameters have the PM_UNSET flag set > when they are defined as a special parameter. During typeset_single() > in builtin.c, at around line 2865, there's this test: > > if (!(pm->flags & PM_UNSET) && !pm->env) > pm->env = addenv(pname, value ? value : getsparam(pname)); > > So the variable won't be exported, because it appears to be unset. This is indeed the source of the bug. The pm->flags never had PM_UNSET removed, so only when the parameter was set did the PM_UNSET get added. I think the answer is simply to unset PM_UNSET explicitly where the flags are assigned. > This is obviously wrong, and it doesn't fail this way in 3.1.6, but I > have not yet had time to track down what the differences are. The story with 3.1.7 is that it does in fact have the same bug, but the parameter was created (from the pre-existing special struct) in createparam with different flags. In 3.0.7, this happens on such occasions: pm->flags = (flags & (PM_EXPORTED | PM_LEFT | PM_RIGHT_B | PM_RIGHT_Z | PM_LOWER | PM_UPPER | PM_READONLY | PM_TAGGED | PM_UNIQUE)) | (pm->flags & (PM_SCALAR | PM_INTEGER | PM_ARRAY | PM_SPECIAL)); while in 3.1.6+, for some reason, the flags are just left as they were before the parameter was created. So the PM_EXPORT was hanging on from the assignment in typeset_single(). This seems wrong, in fact; the 3.0.7 behaviour, tidying up the flags if the parameter is recreated, seems to be right, although with the same fix to remove PM_UNSET. Unless I've missed something. Maybe it's another of those parameter bits that somehow never got transferred to 3.1? Anyway, this patch applies to both 3.0 and 3.1 branches. In the second case you get 2 fuzz and a horrendous number of lines of offset. --- Src/builtin.c.pm Mon Oct 18 17:14:53 1999 +++ Src/builtin.c Sat Feb 5 21:57:53 2000 @@ -2854,7 +2854,7 @@ (apm = (Param) paramtab->getnode(paramtab, pm->ename))) uniqarray((*apm->gets.afn) (apm)); } - pm->flags = (pm->flags | on) & ~off; + pm->flags = (pm->flags | on) & ~(off | PM_UNSET); /* This auxlen/pm->ct stuff is a nasty hack. */ if ((on & (PM_LEFT | PM_RIGHT_B | PM_RIGHT_Z | PM_INTEGER)) && auxlen) -- Peter Stephenson