Re: printf for converting numbers to letters, bug?

[Oliver Kiddle <okiddle@xxxxxxxxxxx>]

Clint Adams wrote:
> > Zsh is (as of 4.2.0) behaving such that, given x='101',
> > 
> > 	printf "%c" $x
> > and
> > 	print -r $x[1]
> > 
> > produce the same output.  That behavior is nearly useless.  (It is how
> > /usr/bin/printf on Linux works, though, so I guess it can be interpreted
> > as a compatibility issue.)

It's how every other printf works and I remember thinking about it when
I implemented zsh's printf. Unlike C, we don't have separate character
and string types. So it is fairly useless but consistent with C printf.

> > If %b interprets the string \0101 as an octal number and prints the
> > corresponding character, why shouldn't %c interpret the string 101 as a
> > decimal number and print the corresponding character?

%b is defined to be like %s except the escape sequences of echo (which
are slightly different to those of the printf format) are understood.
We can't make %c interpret 101 without breaking compatibility.

> Compatibility.  I think an option to do that would be okay, though
> perhaps a bit confusing.  I think it would be nice if bin_printf could
> peek back in time to see if $x had PM_INTEGER set before it got
> expanded, but that seems like more trouble than it's worth.

Peeking back would be nasty. If you really think the feature is worth
having, we could add a new formatting directive (such as %C). What
would you want it to do for values greater than 127 though?

I can't see anything wrong with the %b trick though. Can be used with
\0, \x or \u. Only problem from the perspective of the original post is
that brace expansion uses decimal. I suppose we could allow things like
{8#62..101}

Oliver