* LC_CTYPE weirdness @ 2000-02-01 16:21 Christophe Kalt 2000-02-03 18:41 ` Bart Schaefer 0 siblings, 1 reply; 3+ messages in thread From: Christophe Kalt @ 2000-02-01 16:21 UTC (permalink / raw) To: zsh-workers This one is puzzling me. 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. (e.g. there is a slight chance that this problem isn't coming from zsh, but..) anyhow, for some reason, LC_CTYPE doesn't seem to get exported, yet it is set (as a variable). splitting the line in two ("LC_CTYPE=iso_8859_1;export LC_CTYPE") fixes the problem. Christophe ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: LC_CTYPE weirdness 2000-02-01 16:21 LC_CTYPE weirdness Christophe Kalt @ 2000-02-03 18:41 ` Bart Schaefer 2000-02-05 22:07 ` Peter Stephenson 0 siblings, 1 reply; 3+ messages in thread From: Bart Schaefer @ 2000-02-03 18:41 UTC (permalink / raw) To: Christophe Kalt, zsh-workers Sorry for the delay in responding. On Feb 1, 11:21am, Christophe Kalt wrote: } Subject: LC_CTYPE weirdness } } 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. Once it has become set, then the PM_UNSET flag is gone from the new setting; hence: } splitting the line in two ("LC_CTYPE=iso_8859_1;export LC_CTYPE") fixes } the problem. 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. PWS, if you have some insight, it would be appreciated. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: LC_CTYPE weirdness 2000-02-03 18:41 ` Bart Schaefer @ 2000-02-05 22:07 ` Peter Stephenson 0 siblings, 0 replies; 3+ messages in thread From: Peter Stephenson @ 2000-02-05 22:07 UTC (permalink / raw) To: Christophe Kalt, zsh-workers "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 <pws@pwstephenson.fsnet.co.uk> ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2000-02-05 22:04 UTC | newest] Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2000-02-01 16:21 LC_CTYPE weirdness Christophe Kalt 2000-02-03 18:41 ` Bart Schaefer 2000-02-05 22:07 ` Peter Stephenson
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/zsh/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).