From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20580 invoked from network); 28 Feb 2009 19:52:47 -0000 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.2.5 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by ns1.primenet.com.au with SMTP; 28 Feb 2009 19:52:47 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 99300 invoked from network); 28 Feb 2009 19:52:42 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 28 Feb 2009 19:52:42 -0000 Received: (qmail 21646 invoked by alias); 28 Feb 2009 19:52:37 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 26638 Received: (qmail 21636 invoked from network); 28 Feb 2009 19:52:37 -0000 Received: from bifrost.dotsrc.org (130.225.254.106) by sunsite.dk with SMTP; 28 Feb 2009 19:52:37 -0000 Received: from mail-fx0-f171.google.com (mail-fx0-f171.google.com [209.85.220.171]) by bifrost.dotsrc.org (Postfix) with ESMTP id 04DDA8058F83 for ; Sat, 28 Feb 2009 20:52:33 +0100 (CET) Received: by fxm19 with SMTP id 19so1513364fxm.45 for ; Sat, 28 Feb 2009 11:52:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=wGE0Vzu20RB8kQQ3KGNuLFtLyQl7MJqRK19vc+1AqRg=; b=j++R7vPxCEEgGJpugcNhCbXl8WhcmL5rgZ/jpCpT+ozZIg4oUtEuY/q3G6wAy9zO5B aZe3DMNNCj2vxpgQGYzxiLNoNBTjuUCJAaqJPmnkQzEznou5LFS34zb3qfOePpnzxcuU 7PxZEQsZczGL6pS13CDh/sQWi9oufi0lc7+0Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=n+6IAaAjd9feqdLRTWRtMKTEOYylP8lF3mkrGX6/30x7VPAtwy+Pc8m1NRffo1V6gd LLpYDfMX/BnLOQg+Lplom/YbUZOMNHzPc8EN+ke6ANg/HDaRgvddTJRHNkoXzZLUb+BL Aui7yUPGn2HAPys8U2E/eQI7JQMOrEWlDml7c= MIME-Version: 1.0 Received: by 10.103.24.11 with SMTP id b11mr2020861muj.76.1235850753269; Sat, 28 Feb 2009 11:52:33 -0800 (PST) Date: Sat, 28 Feb 2009 20:52:33 +0100 Message-ID: <2493fbfb0902281152i652d1cd9q27ca8289cef2b3b5@mail.gmail.com> Subject: Re: Echoing of 8-bit-characters broken after 4.3.2? From: Wolfgang Hukriede To: zsh-workers@sunsite.dk Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.92.1/9057/Sat Feb 28 14:56:20 2009 on bifrost X-Virus-Status: Clean Bart wrote: > Try > > export LANG=is_IS.ISO8859-1 > > I discovered this by tab-completing values for LANG. Ok, many thanks, this works so far. I had to change the export to LANG=IS.ISO8859-1 though since otherwise `date' talks in a language which is unknown to me: > date lau 28 feb 2009 19:40:54 CET No, this isn't OSX, but Freebsd-6.4 (with newest ports though by a few days). > The multibyte character handling on OSX appears to be particularly > sensitive to the LANG setting (see my previous mail to Wolfgang). > At the same time, OSX doesn't appear to export a LANG value (or at > least it doesn't on my iMac at work). Freebsd does not export the variable either, but why should it? > I can't precisely reproduce the above; I get things like > > schaefer<263> touch x<00c3><00c3><00c3>x > > or > > schaefer<263> touch xinsert-composed-char:180: character not in range > > before I ever get as far as creating the file. Maybe there's some > additional character munging happening in transit of the email so > I'm not using the correct input. This is not so here. Only just the echoing of the character fails unless LANG is set. Tab completion worked in 4.3.2 and works with LANG set. > Wolfgang, if you're reading this, something that I forgot to mention in > my reply to you is that sometime during 4.3.x zsh began to pay closer > attention to characters that are absent from the declared LANG character > set and to either refuse to process them at all, or to render them as > digits surrounded by angle brackets. It no longer blindly passes those > characters around unprocessed, so things that "worked" before because > xterm dealt with the processing will now appear to "fail" because the > shell is trying harder to do the right thing internally. Yes, I suspected so. But what is the benefit of it? Perhaps to make certain the shell can assume unicode as the default? Would an explicit setopt (to remove the ambiguity) not be a viable/better alternative? Looking up "man 1 locale" I found the bug section below. Might this be significant? DESCRIPTION ... -m Print names of all available charmaps. BUGS Since FreeBSD does not support charmaps in their POSIX meaning, locale emulates the -m option using the CODESETs listing of all available locales.