Re: printf %b

[Peter Stephenson <pws@xxxxxxx>]

Stephane Chazelas <Stephane_Chazelas@xxxxxxxx> 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 <NL>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