Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: insert-unicode-char
- X-seq: zsh-workers 22030
- From: Peter Stephenson <pws@xxxxxxx>
- To: zsh-workers@xxxxxxxxxx
- Subject: Re: insert-unicode-char
- Date: Fri, 25 Nov 2005 11:10:23 +0000
- In-reply-to: <20051124145701.GB1880@xxxxxxxxxxxxxxxxxxxxxxxxxx>
- Mailing-list: contact zsh-workers-help@xxxxxxxxxx; run by ezmlm
- Organization: Cambridge Silicon Radio
- References: <20051124140854.GA25283@xxxxxxxxxxxxxxxxxxxxxxxxxx> <20051124143305.GA1880@xxxxxxxxxxxxxxxxxxxxxxxxxx> <20051124145701.GB1880@xxxxxxxxxxxxxxxxxxxxxxxxxx>
"Zvi Har'El" <rl@xxxxxxxxxxxxxxxxxxx> 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 <pws@xxxxxxx> 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
Messages sorted by:
Reverse Date,
Date,
Thread,
Author