LC_CTYPE weirdness

LC_CTYPE weirdness

[Christophe Kalt]

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

Re: LC_CTYPE weirdness

[Bart Schaefer]

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

Re: LC_CTYPE weirdness

[Peter Stephenson]

"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>