From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12475 invoked from network); 6 Mar 2008 17:13:43 -0000 X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.4 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by ns1.primenet.com.au with SMTP; 6 Mar 2008 17:13:43 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 51187 invoked from network); 6 Mar 2008 17:13:36 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 6 Mar 2008 17:13:36 -0000 Received: (qmail 19011 invoked by alias); 6 Mar 2008 17:13:34 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 24694 Received: (qmail 18997 invoked from network); 6 Mar 2008 17:13:34 -0000 Received: from bifrost.dotsrc.org (130.225.254.106) by sunsite.dk with SMTP; 6 Mar 2008 17:13:34 -0000 Received: from vms044pub.verizon.net (vms044pub.verizon.net [206.46.252.44]) by bifrost.dotsrc.org (Postfix) with ESMTP id 319728029404 for ; Thu, 6 Mar 2008 18:13:28 +0100 (CET) Received: from torch.brasslantern.com ([71.121.18.67]) by vms044.mailsrvcs.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPA id <0JXB001BTJN29QN0@vms044.mailsrvcs.net> for zsh-workers@sunsite.dk; Thu, 06 Mar 2008 11:09:04 -0600 (CST) Received: from torch.brasslantern.com (localhost.localdomain [127.0.0.1]) by torch.brasslantern.com (8.13.1/8.13.1) with ESMTP id m26H92oh021799 for ; Thu, 06 Mar 2008 09:09:02 -0800 Received: (from schaefer@localhost) by torch.brasslantern.com (8.13.1/8.13.1/Submit) id m26H916f021798 for zsh-workers@sunsite.dk; Thu, 06 Mar 2008 09:09:01 -0800 Date: Thu, 06 Mar 2008 09:09:01 -0800 From: Bart Schaefer Subject: Re: printf %s in UTF-8 is not POSIX-compliant In-reply-to: <200803051041.m25AfmUc031042@news01.csr.com> To: zsh-workers@sunsite.dk Message-id: <080306090901.ZM21797@torch.brasslantern.com> MIME-version: 1.0 X-Mailer: OpenZMail Classic (0.9.2 24April2005) Content-type: text/plain; charset=us-ascii References: <20080304012917.GA15833@prunille.vinc17.org> <200803040940.m249e7DC012517@news01.csr.com> <20080305002721.GF15833@prunille.vinc17.org> <200803051041.m25AfmUc031042@news01.csr.com> Comments: In reply to Peter Stephenson "Re: printf %s in UTF-8 is not POSIX-compliant" (Mar 5, 10:41am) X-Virus-Scanned: ClamAV 0.91.2/6153/Thu Mar 6 14:59:13 2008 on bifrost X-Virus-Status: Clean On Mar 5, 10:41am, Peter Stephenson wrote: } } Is it time to introduce a separate "bash" emulation (meaning smart, } interactive shell not necessarily 100% POSIX compatible) and } document that "sh" emulation is aimed at POSIX compatibility? After reading some of the more recent posts on this thread, I've got an opinion on this. I think "emulate sh" should emulate the POSIX shell to the greatest extent possible. If that means turning off MULTIBYTE, turn it off. (Of course there are still subtle differences between starting the shell as "sh" and running "emulate sh" after it has started. There probably isn't any way to entirely resolve that.) However, if "emulate bash" is going to mean something other than a synonym for "sh", then some effort should be put into being a bit closer to bash than it's currently possible to be. For example, at least set the various BASH_* options, the way "emulate csh" sets the smattering of CSH_* options. Of course "emulate bash" isn't even in the documentation at present. (The "Compatibilty" section referenced from the "emulate" command doesn't discuss csh, either, even though the "emulate" doc does list csh among the possible arguments.) A final thought on MULTIBYTE: Is it perhaps reasonable to split this into two options, one that affects line editor operations and one that affects internals? If someone does "emulate sh; setopt zle" it seems there might be some expectation that ZLE can adapt to a terminal that displays multibyte even if the input is all treated as raw bytes once accept-line hands it off. That might mean that e.g. _main_complete needs to look at the state of ZLE_MULTIBYTE (or whatever) and setopt MULTIBYTE locally to correspond. Other widgets could also be affected, so the emphasis here is on "reasonable." (Possible workaround: setopt MULTIBYTE in zle_line_init and unset it again in preexec.)