Re: printf \045 (or whatever the character code for % is)

[Peter Stephenson <Peter.Stephenson@csr.com>]

On Wed, 5 Jan 2011 20:46:12 -0800
Bart Schaefer <schaefer@brasslantern.com> wrote:
> } 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.

That's kind of why print & printf really ought to be separate, with
common subroutines where needed (the lack of modularity in bin_print()
is one of the big issues).  But that's moot for now...

> 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:

That's sneaky, that should be OK.

> @@ -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';

Presumably since we're contracting an escape sequence there's always enough
allocated space for the extra '%'.

> 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.

There's no particularly well-defined order in the enum, although the
more recherché options tend to be later (but only because they were
added later).

Unless we go down the route of separate builtin handlers, I think it
would be better to keep printf and print -f in sync for now. For one
thing, making them different puts yet another strain on bin_print(); for
another, we haven't yet gone into the details of where printf actually
needs to be different from print (we'd need to look at the relevant
standards for printf to see where the code is doing the wrong thing at
present).

-- 
Peter Stephenson <pws@csr.com>            Software Engineer
Tel: +44 (0)1223 692070                   Cambridge Silicon Radio Limited
Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, UK


Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom