From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6676 invoked from network); 25 Nov 2005 11:10:36 -0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.0 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by ns1.primenet.com.au with SMTP; 25 Nov 2005 11:10:36 -0000 Received: (qmail 23509 invoked from network); 25 Nov 2005 11:10:30 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 25 Nov 2005 11:10:30 -0000 Received: (qmail 22187 invoked by alias); 25 Nov 2005 11:10:28 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 22030 Received: (qmail 22178 invoked from network); 25 Nov 2005 11:10:27 -0000 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by sunsite.dk with SMTP; 25 Nov 2005 11:10:27 -0000 Received: (qmail 23211 invoked from network); 25 Nov 2005 11:10:27 -0000 Received: from cluster-d.mailcontrol.com (HELO rly37d.srv.mailcontrol.com) (217.69.20.190) by a.mx.sunsite.dk with SMTP; 25 Nov 2005 11:10:26 -0000 Received: from exchange03.csr.com ([62.189.241.194]) by rly37d.srv.mailcontrol.com (MailControl) with ESMTP id jAPBAOJ4009164 for ; Fri, 25 Nov 2005 11:10:24 GMT Received: from news01 ([10.103.143.38]) by exchange03.csr.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 25 Nov 2005 11:13:10 +0000 Date: Fri, 25 Nov 2005 11:10:23 +0000 From: Peter Stephenson To: zsh-workers@sunsite.dk Subject: Re: insert-unicode-char Message-Id: <20051125111023.350da990.pws@csr.com> In-Reply-To: <20051124145701.GB1880@fermat.math.technion.ac.il> References: <20051124140854.GA25283@fermat.math.technion.ac.il> <20051124143305.GA1880@fermat.math.technion.ac.il> <20051124145701.GB1880@fermat.math.technion.ac.il> Organization: Cambridge Silicon Radio X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Nov 2005 11:13:10.0627 (UTC) FILETIME=[38511330:01C5F1B1] X-Scanned-By: MailControl A-05-40-01 (www.mailcontrol.com) on 10.68.0.147 "Zvi Har'El" wrote: > Another remark: In the solaris 9 system, I have two copies of libiconv > installed: one in /usr/lib (the solaris native), and one in /usr/local/lib > (from GNU libiconv-1.10), and the latter directory is in the LD_LIBRARY_PATH > both in installation time and in run time, and ldd =zsh shows that it uses > /usr/local/lib/libiconv.so.2. On the Redhat system, where unicode esacpe > sequences work, I am using glibc. > > On Thu, 24 Nov 2005 16:33:05 +0200, Zvi Har'El wrote: >> I now checked this also on our solaris systems. The situation is that both >> insert-composed-char and insert-unicode-char fail, on the line which tries to >> print a unicode esacep sequence. However, on these machines, I get >> 'zsh: cannot do charset conversion' on such print commands (e.g., print >> \\u21 , which should print a bang!), a message which is generated by >> Src/utils.c. I am using a LC_CTYPE=en_US.UTF-8 locale, and zsh in configured >> with --enable-multibyte (which is a mistary by itself, since on my RedHat >> system, this flag is not needed since configure figures it out by itself). It's quite possible that the multiple libiconvs are significant, since it works OK on Solaris 8 here. The error message and the configuration suggest this call is failing: cd = iconv_open(nl_langinfo(CODESET), "UCS-4BE"); although it's possible it's not using the iconv code at all for some reason, which would happen if neither HAVE_ICONV nor any of the alternative conversion types were available. The dependence on the shared library might conceivably be indirect. We don't have a Solaris 9 for trying out multibyte mode on, but I know that Solaris 8 doesn't set __STDC_ISO_10646__, which we're using to detect the capabilities automatically---it saves a lot of configuration probing. It sounds like it probably isn't set in your case, otherwise the shell would use wctomb() rather than iconv, avoiding the other problem. With enough automated tests for things like the effect of wctomb() we could probably avoid all this, but that's hard work. -- Peter Stephenson Software Engineer CSR PLC, Churchill House, Cambridge Business Park, Cowley Road Cambridge, CB4 0WZ, UK Tel: +44 (0)1223 692070 This message has been scanned for viruses by BlackSpider MailControl - www.blackspider.com