From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3416 invoked from network); 4 Jan 2007 15:37:14 -0000 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.7 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by ns1.primenet.com.au with SMTP; 4 Jan 2007 15:37:14 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 65002 invoked from network); 4 Jan 2007 15:37:08 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 4 Jan 2007 15:37:08 -0000 Received: (qmail 26635 invoked by alias); 4 Jan 2007 15:37:05 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 23086 Received: (qmail 26625 invoked from network); 4 Jan 2007 15:37:04 -0000 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by sunsite.dk with SMTP; 4 Jan 2007 15:37:04 -0000 Received: (qmail 64726 invoked from network); 4 Jan 2007 15:37:04 -0000 Received: from cluster-c.mailcontrol.com (168.143.177.190) by a.mx.sunsite.dk with SMTP; 4 Jan 2007 15:37:00 -0000 Received: from cameurexb01.EUROPE.ROOT.PRI ([62.189.241.200]) by rly11c.srv.mailcontrol.com (MailControl) with ESMTP id l04FaTtF030754 for ; Thu, 4 Jan 2007 15:36:45 GMT Received: from news01.csr.com ([10.103.143.38]) by cameurexb01.EUROPE.ROOT.PRI with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Jan 2007 15:36:31 +0000 Date: Thu, 4 Jan 2007 15:36:12 +0000 From: Peter Stephenson To: Zsh hackers list Subject: Re: printf %b Message-Id: <20070104153612.7aeb604f.pws@csr.com> In-Reply-To: <20061227145818.GA4369@sc> References: <20061227145818.GA4369@sc> Organization: Cambridge Silicon Radio X-Mailer: Sylpheed version 2.2.10 (GTK+ 2.10.4; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Jan 2007 15:36:31.0552 (UTC) FILETIME=[1BB3A400:01C73016] X-Scanned-By: MailControl A-06-00-00 (www.mailcontrol.com) on 10.67.0.121 Stephane Chazelas wrote: > Hiya, > > just noticed that > > printf %b '\0123' > > doesn't work anymore as it used to and as SUSv3 specifies > (should output S, and not 3). Thanks for noticing. That was a mistake when I updated the getkeystring() interface from it's previous Chasm-City-after-the-melding-plague look. The following restores the previous behaviour. However, now I look at it, it all seems a bit weird. We will either handle \0DDD, or \DDD (D is 0 to 7), but not both. So print '\123' outputs S, but print '\0123' outputs newline + '3'. It's not necessarily correct that those that currently handle '\0123' shouldn't handle '\123': presumably this is supposed to impose the standardised form as written, but actually bash allows the shorthand, i.e. printf %b '\0123' printf %b '\123' are both handled. (This isn't true of echo, which passes \123 straight through... this is the same as zsh.) It appears to be intelligent enough to handle '\012S' as a newline and an S, too. /usr/bin/printf on both GNU and Solaris only accepts '\123' (i.e. the first is newline + 3), so this is like the behaviour *before* the patch below! It's even less clear the other way round; unless I've missed something it's not even documented that this is how print with no options works. The documentation says: - \0NNN works for "echo" (OK) - printf's arguments are like echo (OK, need \0NNN. However, Stephane... this means that printf '\123' *doesn't* print S any more, it needs '\0123', too; that's changed back with the fix below.) - print without options is the same as echo except for some additions (\C-..., \M-..., \E) (WRONG: \0NNN doesn't work but \NNN does) - \NNN works for bindkey sequences (and hence for "print -b") (OK). The same goes for \0xNN and \xNN. My first inclination is to bury my head in the sand and pretend it's not happening, but maybe we can do better. - Handling \0NNN everywhere is a bit fraught, since it changes the meaning of three-digit codes with another digit following. - Handling \NNN in printf is less problematic: it's an incompatibility but given the bash behaviour people wouldn't necessarily have assumed this was passed straight through on the occasions when \0NNN was handled. (We definitely don't want to handle \NNN specially in echo.) I will anyway commit the following to restore the old behaviour. Index: Src/zsh.h =================================================================== RCS file: /cvsroot/zsh/zsh/Src/zsh.h,v retrieving revision 1.103 diff -u -r1.103 zsh.h --- Src/zsh.h 3 Dec 2006 21:07:18 -0000 1.103 +++ Src/zsh.h 4 Jan 2007 14:57:28 -0000 @@ -1955,7 +1955,8 @@ enum { /* * Handle octal where the first digit is non-zero e.g. \3, \33, \333 - * \0333 etc. is always handled. + * Otherwise \0333 etc. is handled, i.e. one of \0123 or \123 will + * work, but not both. */ GETKEY_OCTAL_ESC = (1 << 0), /* @@ -1990,7 +1991,7 @@ /* echo builtin */ #define GETKEYS_ECHO (GETKEY_BACKSLASH_C) /* printf format string */ -#define GETKEYS_PRINTF (GETKEY_OCTAL_ESC|GETKEY_BACKSLASH_C) +#define GETKEYS_PRINTF (GETKEY_BACKSLASH_C) /* Full print without -e */ #define GETKEYS_PRINT (GETKEY_OCTAL_ESC|GETKEY_BACKSLASH_C|GETKEY_EMACS) /* bindkey */ Index: Test/B03print.ztst =================================================================== RCS file: /cvsroot/zsh/zsh/Test/B03print.ztst,v retrieving revision 1.16 diff -u -r1.16 B03print.ztst --- Test/B03print.ztst 23 Sep 2006 06:55:29 -0000 1.16 +++ Test/B03print.ztst 4 Jan 2007 14:57:28 -0000 @@ -259,3 +259,7 @@ printf $'%\0' 1:explicit null after % in format specifier ?(eval):printf:1: %: invalid directive + + printf '%b\n' '\0123' +0:printf handles \0... octal escapes in replacement text +>S To access the latest news from CSR copy this link into a web browser: http://www.csr.com/email_sig.php