From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 43 invoked by alias); 6 Jan 2011 04:46:40 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 28573 Received: (qmail 5393 invoked from network); 6 Jan 2011 04:46:38 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 Received-SPF: none (ns1.primenet.com.au: domain at closedmail.com does not designate permitted sender hosts) From: Bart Schaefer Message-id: <110105204614.ZM8225@torch.brasslantern.com> Date: Wed, 05 Jan 2011 20:46:12 -0800 In-reply-to: <20110105173944.47123402@pws-pc.ntlworld.com> Comments: In reply to Peter Stephenson "Re: printf \045 (or whatever the character code for % is)" (Jan 5, 5:39pm) References: <20101229211155.GA22720@stack.nl> <20110105173944.47123402@pws-pc.ntlworld.com> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: "Zsh Hackers' List" Subject: Re: printf \045 (or whatever the character code for % is) MIME-version: 1.0 Content-type: text/plain; charset=us-ascii On Jan 5, 5:39pm, Peter Stephenson wrote: } } > POSIX's description assumes that the backslash escapes and format } > specifications are processed in one pass and simply says that an } > octal escape sequence shall write the corresponding byte. If they } > are separate passes the backslash escape removal step needs to know } > about percent signs. } } That's a reasonable assumption, but the function handling print is an } appalling mess so it's not easy to fix without a major rewrite. The octal escapes are all handled by getkeystring(). There's already a special macro GETKEYS_PRINTF_FMT which (unfortunately?) is used for both "printf" and "print -f". } The code for printf doesn't really have any business being associated } with the code for print, they're there for different purposes entirely } based on completely different specifications. At the moment printf } does the same as 'print -f', so it has all the same oddities as print } whether it should or not. I'm not entirely sure that's true. The printf builtin doesn't accept any options, which means that except for the initial getkeystring(), nearly everything in bin_print() is ignored until you get down to the part that handles the format spec ... and that can't be replaced by e.g. sprintf() because of misc. special formats like %b and %q. } (In my opinion, anyone deliberately asking for combined print and } printf behaviour deserves everything they get so I'm perfectly happy } to let 'print -f' fester while standardising printf.) Although we could rip the format handling out of bin_print() and create a new bin_printf() [which would be called by "print -f"?] we'd still need something akin to getkeystring() for the octal escapes. } However, I never get volunteers for tidying the shell up, so we're } probably stuck until someone gets fed up enough to look into it. GETKEYS_PRINTF_FMT expands to GETKEY_OCTAL_ESC|GETKEY_BACKSLASH_C ... seems as though an additional flag to getkeystring() could be used to cause \045 to expand to %% as a special case, something like this in utils.c: @@ -5517,6 +5522,8 @@ } *t++ = zstrtol(s + (*s == 'x'), &s, (*s == 'x') ? 16 : 8); + if ((how & GETKEY_PRINTF) && t[-1] == '%') + *t++ = '%'; if (svchar) { u[3] = svchar; svchar = '\0'; The flag bits for "how" are an enum in zsh.h and I'm undecided whether to renumber them or just add another to the end, so I have't included a complete patch. Also I don't know whether the intent is that \045 (and \x25) should become %% only for "printf" or also for "print -f", so no patch for builtin.c yet either. --