From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3639 invoked from network); 11 May 2007 17:56:21 -0000 X-Spam-Checker-Version: SpamAssassin 3.2.0 (2007-05-01) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=no version=3.2.0 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by ns1.primenet.com.au with SMTP; 11 May 2007 17:56:21 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 58563 invoked from network); 11 May 2007 17:56:15 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 11 May 2007 17:56:15 -0000 Received: (qmail 25006 invoked by alias); 11 May 2007 17:56:12 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 23431 Received: (qmail 24997 invoked from network); 11 May 2007 17:56:11 -0000 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by sunsite.dk with SMTP; 11 May 2007 17:56:11 -0000 Received: (qmail 58226 invoked from network); 11 May 2007 17:56:11 -0000 Received: from cluster-c.mailcontrol.com (168.143.177.190) by a.mx.sunsite.dk with SMTP; 11 May 2007 17:56:07 -0000 Received: from cameurexb01.EUROPE.ROOT.PRI ([62.189.241.200]) by rly15c.srv.mailcontrol.com (MailControl) with ESMTP id l4BHu378031893 for ; Fri, 11 May 2007 18:56:04 +0100 Received: from news01.csr.com ([10.103.143.38]) by cameurexb01.EUROPE.ROOT.PRI with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 May 2007 18:56:03 +0100 Date: Fri, 11 May 2007 18:56:02 +0100 From: Peter Stephenson To: zsh-workers@sunsite.dk Subject: Re: problems with 4.3.4 and Tru64 Message-Id: <20070511185602.f76af8ed.pws@csr.com> In-Reply-To: <2DF07A7A-0112-1000-87C3-08869130C191-Webmail-10013@mac.com> References: <20070510175541.GA67479@redoubt.spodhuis.org> <20070510222647.GA45037@redoubt.spodhuis.org> <200705110928.l4B9Sobe019086@news01.csr.com> <2DF07A7A-0112-1000-86BB-08869130C191-Webmail-10013@mac.com> <2DF07A7A-0112-1000-87C3-08869130C191-Webmail-10013@mac.com> Organization: Cambridge Silicon Radio X-Mailer: Sylpheed version 2.2.10 (GTK+ 2.10.8; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 11 May 2007 17:56:03.0011 (UTC) FILETIME=[A3F12930:01C793F5] X-Scanned-By: MailControl A-07-07-00 (www.mailcontrol.com) on 10.67.0.125 Jordan Breeding wrote: > Sorry to reply to myself, but I just paid a little bit more attention > and I figured out something else interesting. The extra characters > that appear in the Terminal itself just before the output from echo > are the multibyte characters only, which are missing from the ${1} > being inserted into the Terminal title. This part seems to be OS X > (Terminal.app) specific, as if I use zsh through a remote Terminal > the behaviour will differ (putty will display > hlp in the title which I am assuming are just > the bytes that it is seeing). Anyway, I will probably just not use > preexec() anymore for now. Is there are way to display multibyte > characters as the base singlebyte character for the preexec string? > Or possible just replace multibyte characters with "?" or something, > just so my preexec would at least partially work? I'm glad things are working better... I'd be happy to put any generic workarounds in the shell itself, but it's probably too difficult for a terminal-specific problem, if that's what this is. As for detecting multibyte characters: presumably all characters with codes over 127 are going to be multibyte, so it is possible to detect such a string: % foo=3D"=E4" % print $(( #foo )) 228 However, this just tests the first character; you'd have to loop over the entire string to do it which is a bit of a nuisance: local line=3D${(%):-'\e]2;%n@%m %0~ (%30>...>'${1}'%>>%)\a'} char local -a arr arr=3D(${(s..)line}) integer i for (( i =3D 1; i <=3D ${#arr}; i++)); do char=3D${arr[i]} (( #char > 127 )) && arr[i]=3D"?" done print -n ${(j..)arr} (I did test this.) I wonder if the shell is misinterpreting codes within the ${1} in print -Pn "\e]2;%n@%m %0~ (%30>...>${1}%>>%)\a" ? If you just do print -P "" from the command line with what was in ${1} does everything look OK? (This is rather a long shot; I don't see how the shell could misplace characters like that, but it might be getting the handling of characters sufficiently wrong that the terminal driver is getting confused.) --=20 Peter Stephenson Software Engineer CSR PLC, Churchill House, Cambridge Business Park, Cowley Road Cambridge, CB4 0WZ, UK Tel: +44 (0)1223 692070 To access the latest news from CSR copy this link into a web browser: http= ://www.csr.com/email_sig.php To get further information regarding CSR, please visit our Investor Relatio= ns page at http://ir.csr.com/csr/about/overview