Tcl Source Code

tcl crashes when LC_CTYPE is set to one of
the zh_CN.GB* locales (e.g., zh_CN.GB2312). 
I encountered this problem with tcl 8.3.3 in both
redhat-7.2 and redhat-7.3 distributions and I had to
removed the file gb2312.enc in order to run tcl
scripts (I don't need Chinese characters with tcl anyway). 

Linbo Zhang

Logged In: YES 
user_id=72656

OK, it appears that the fix to this is really a bit more complex 
for the Tcl *AND* Tk sides.  The old gb2312.enc had some 
validity - just not as the basic "gb2312" that people thought 
(where they really mean euc-cn).  I am adding back the old 
version as gb2312-raw.enc (as Perl does as well, where 
gb2312 == euc-cn).  This encoding is needed on Unix for the 
Tk font alias of gb2312* fonts.

We hope to make the font aliases and fallbacks more 
transparent (and controllable) in 8.5, but these pair of fixes 
appear to (a) make startup correct and usable and (b) make 
simplified chinese still display correctly on unix (tested on 
SuSE 7.3 with isas-sont ti-..-gb2312.1980 fonts).

File Added - 50370: 2003-5-14.txt

Logged In: YES 
user_id=72656

I am "solving" this by copying euc-cn.enc over gb2312.enc.  It 
appears that it what almost everybody means when they say 
gb2312.  More info about this is in the attached chat log.  
Somebody below mentions that GBK should be gb2312, but 
other resources mention euc-cn instead (in fact, that is what 
perl does), so that is how we went.  Consider this fix flexible if 
someone with more knowledge wants to explain it all to me.

Tcl 8.4.3 and 8.5a0 have this change.

Logged In: YES 
user_id=25775

This problem still exists in 8.4.2; I just got a report from
a Debian user.  Note that if I replace gb2312.enc with
euc-cn.enc, then it no longer crashes, which strongly
suggests that the gb2312.enc file is broken.

Logged In: NO 

I'm using xcin for Chinese input because I feel
it's more stable than miniChinput.
miniChinput is always causing problems, and
easily crashes with rh7.2/7.3.

The version of xcin that i'm using is based on 
the version 2.5.2, and patched by Jim Chen
to allow input of words.

Another note: it seems that xcin does not
work with the XFree86-4.2.0 of rh7.3. 
What I'm running now is rh7.3 + XFree86-4.1.0

ZLB

Logged In: YES 
user_id=550390

Hi hobbs,

I tried tcl8.4a4 but  the problem is still there. The error
message is unreadable:

#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?root#?tcl8#?4a4/lib/tcl8#?#?#?#?root#?lib/tcl8#?#?#?#?root#?tcl8#?4a4/librar#?#?#?root#?librar#?#?#?root#?tcl8#?4a4/librar#?#?#?tcl8#?4a4/librar#?#?#?usr/local/lib/tcl8#?#?#?#?#?@P#?#?#?#?!c#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?#?

What it means? I don't know. I noticed this problem has been
discussed at bug #218468. Unfortunally, it has been there so
long. I believe it will help if you can add the patch to
force using cp936, otherwise anyone use Chinese Linux need
to patch/fix himself. I haven't seen any bug reported
against this patch anywhere so far.

But I don't know ZLB's problem with Chinese input. I use
miniChinput and it works fine for me.

Logged In: NO 

Yes the startup problem can be solved by replacing
gb2312.enc with a symbolic link to cp936.enc, and
even Chinese characters can be correctly displayed
with both tcl/tk 8.3 and 8.4. But Chinese input does
not work (I was using xcin for Chinese input),
maybe because tcl/tk does not support XIM?

LB

Logged In: NO 

No, the problem is not at GB2312 locale table, nor is it at
the way tcl dealing with locales. It is (for historical
reason) because most (if not all) of the GB2312 locales used
in Chinese fonts are actually GBK(code page 936). That's why
the patch I copied from www.linuxforum.net works here.

Another quick fix is copy cp936.enc to gb2312.enc in tcl's
encoding directory. Well, I don't know how 8.4 has improved
on i18n, just hope these can be helpfull to you, again.

Only

Logged In: NO 

I have installed tcl/tk 8.4a4 (tcl was built with
'--enable-langinfo' option, and I had to keep
the files libtcl.so.0, libtk.so.0, and
/usr/bin/wish, because many RH packages
depend on them). It seems that the problem
still exists. E.g., 

    $ LC_CTYPE=zh_CN.GB2312 wish8.4

does not work. The problem may be in
my GB2312 locale?

ZLB

Logged In: YES 
user_id=72656

It should be noted that 8.4 has enabled the use of 
nl_langinfo in the Unix startup.  I believe this corrects 
this problem, but it was not backported to 8.3.x.  If 
someone on a Chinese system could please test the 8.4 
sources for correctness, that would help.

Logged In: NO 

I tried the above patch with tcl-8.3.3-67 (RH7.3) and it
seemed to solve the (startup) problem. Thanks.

I may have misstated my problem in my first mail.
The real problem was that TCL can't start up
("Tcl_Init failed: Can't find a usable init.tcl ...")
with the zh_CN.GB* locales.

Linbo

diff -burN tcl8.3.3.orig/unix/tclUnixInit.c
tcl8.3.3/unix/tclUnixInit.c
--- tcl8.3.3.orig/unix/tclUnixInit.c Wed Apr 4 06:54:39 2001
+++ tcl8.3.3/unix/tclUnixInit.c Mon May 20 20:02:45 2002
@@ -56,6 +56,7 @@
 } LocaleTable;
 
 static CONST LocaleTable localeTable[] = {
+    {"chinese",                "cp936"},
     {"ja_JP.SJIS",     "shiftjis"},
     {"ja_JP.EUC",      "euc-jp"},
     {"ja_JP.eucJP",     "euc-jp"},
@@ -90,6 +91,20 @@
     {"ru_SU",          "iso8859-5"},           
 
     {"zh",             "cp936"},
+    {"zh_CN",          "cp936"},
+    {"zh_CN.GB2312",   "cp936"},
+    {"zh_CN.GBK",      "cp936"},
+    {"zh_CN.GB18030",  "cp936"},
+#ifdef hpux
+    {"zh_CN.hp15CN",   "cp936"},
+#endif
+    {"zh_CN.gb2312",   "cp936"},
+    {"zh_CN.gbk",      "cp936"},
+    {"zh_CN.gb18030",  "cp936"},
+    {"zh_HK",          "cp950"},
+    {"zh_TW",          "cp950"},
+    {"zh_TW.Big5",     "cp950"},
+    {"zh_TW.big5",     "cp950"},
 
     {NULL, NULL}
 };

Logged In: NO 

Hello,

I saw this patch posted on www.linuxforum.net for this
issue. Hope this will help.

--- tcltk-8.3.2/tcl8.3.2/unix/tclUnixInit.c.locale      Thu
May 10 16:32:41 2001+++
tcltk-8.3.2/tcl8.3.2/unix/tclUnixInit.c     Thu May 10
16:37:23 2001
@@ -56,6 +56,7 @@
 } LocaleTable;

 static CONST LocaleTable localeTable[] = {
+    {"chinese",        "cp936"},
     {"ja_JP.SJIS",     "shiftjis"},
     {"ja_JP.EUC",      "euc-jp"},
     {"ja_JP.JIS",      "iso2022-jp"},
@@ -89,6 +90,18 @@
     {"ru_SU",          "iso8859-5"},

     {"zh",             "cp936"},
+    {"zh_CN",          "cp936"},
+    {"zh_CN.GBK",              "cp936"},
+    {"zh_CN.GB2312",           "cp936"},
+#ifdef hpux
+    {"zh_CN.hp15CN",           "cp936"},
+#endif
+    {"zh_CN.gbk",              "cp936"},
+    {"zh_CN.gb18030",          "cp936"},
+    {"zh_HK",          "cp950"},
+    {"zh_TW",          "cp950"},
+    {"zh_TW.Big5",             "cp950"},
+    {"zh_TW.big5",             "cp950"},

     {NULL, NULL}
 };