From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22887 invoked from network); 28 Feb 2009 22:01:04 -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 22:01:04 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 39355 invoked from network); 28 Feb 2009 22:00:58 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 28 Feb 2009 22:00:58 -0000 Received: (qmail 21762 invoked by alias); 28 Feb 2009 22:00:50 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 26644 Received: (qmail 21740 invoked from network); 28 Feb 2009 22:00:48 -0000 Received: from bifrost.dotsrc.org (130.225.254.106) by sunsite.dk with SMTP; 28 Feb 2009 22:00:48 -0000 Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.185]) by bifrost.dotsrc.org (Postfix) with ESMTP id 0212E8058F83 for ; Sat, 28 Feb 2009 23:00:44 +0100 (CET) Received: by mu-out-0910.google.com with SMTP id i10so584080mue.1 for ; Sat, 28 Feb 2009 14:00:44 -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=jMTcczFJpGb6aVcuF1iY9JXZgpjMWPjf5OJ9oV9aGWM=; b=lyS/noIb3dFcVO0oyK2OFcd6/8cJ4bSdcRhna7JDBQR1kwJETUNSk4SjbNz6QK5ZZB 8xffyXXqC88zBLserrJmisdwevypzox4tV2C06eAFtmfwj/8iiyZ5zUT26r5pUoPDHWk wnYZjYCmgJrGVx8dV0DL55Yp4Kt5E5LSVsTv0= 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=P4RPv2qh5prZjQJ4qcnIcgTbkGMpjgmTmARRfWSEyIccVPPYdbv08edpzADYagJVDw QjZ48Q1IY10jBOQ6EZO6rDRrhAHIbwWhhFs2mdNnzDeC91dK7q1rO4Xox8pgWH4gAo18 jkO4b+55IozlWllhlrlesoYzh4L2lLVWCdeEc= MIME-Version: 1.0 Received: by 10.103.228.19 with SMTP id f19mr2085108mur.18.1235858444243; Sat, 28 Feb 2009 14:00:44 -0800 (PST) Date: Sat, 28 Feb 2009 23:00:44 +0100 Message-ID: <2493fbfb0902281400r5d56ef91r74d55433eddf51be@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 Andrey wrote: > Because this is established standard to define your character set > properties. Without it applications should assume C (or POSIX) locale > that basically corresponds to standard ASCII. Should the character set properties not be set by LC_CTYPE? As far as I can tell LANG sets more than that? Do I understand correctly that LANG is zsh-specific? (On my box, man 3 setlocale does not have it.) > So I would be surprised if > zsh were the only program that had issues with non-ASCII characters. At least emacs passes them through without ado. There's only one other program that I had problems with in that respect. (That's unicode only.) Looks like more will come... > FreeBSD could provide some other means to define local though. Not that I know of. > Because blindly emitting arbitrary character sequence to terminal may > have completely undefined effects and screw up display to the point that > you need hard reset (town legend also is that you can cause you terminal > to echo back any sequence like "rm -rf" as input back to shell ...) Urban legends aside, this may be. Otoh... I've been using zsh since at least 10 years almost exclusively and quite intensely and have used 8-bit-characters all the time (all on xterms), but any display distortion never happened to me. This is probably due to the fact that filenames are mostly under ones own control. I suffered display distortion from reading emails though, but the shell could not have done anything about that. Correctness of vt100-control-sequences cannot be monitored either. Therefore I think passing-through of eight bit characters should be configurable. But I still do not understand how am I supposed to do that (without triggering side effects). Why is PRINT_EIGHT_BIT constricted to affect tab-completion only?