(Fwd) printf for converting numbers to letters, bug?

(Fwd) printf for converting numbers to letters, bug?

[Bart Schaefer]

Looks like "%c" is interpreting the argument as a string and printing
the first character thereof.  It should work more like %d, shouldn't it?

--- Forwarded mail from Matthias Kopfermann <matthias@kopfermann.org>

Date: Fri, 26 Mar 2004 16:29:13 +0100
From: Matthias Kopfermann <matthias@kopfermann.org>
To: schaefer@brasslantern.com
Subject: printf for converting numbers to letters, bug?

hi bart (hero:) )!

I wanted to do printf "%c\n" {65..101}
to get some ascii-letters and did not succeed.

Is this wanted behaviour?

        Matthias


---End of forwarded mail from Matthias Kopfermann <matthias@kopfermann.org>

Re: (Fwd) printf for converting numbers to letters, bug?

[Clint Adams]

> Looks like "%c" is interpreting the argument as a string and printing
> the first character thereof.  It should work more like %d, shouldn't it?

Not according to POSIX; the argument to %b, %c, or %s is to be
interpreted as a string.

If we had octal brace expansion, he could do something like
printf "%b\n" \\0{101..145}

Re: printf for converting numbers to letters, bug?

[Bart Schaefer]

On Mar 26, 12:00pm, Clint Adams wrote:
} Subject: Re: (Fwd) printf for converting numbers to letters, bug?
}
} > Looks like "%c" is interpreting the argument as a string and printing
} > the first character thereof.  It should work more like %d, shouldn't it?
} 
} Not according to POSIX; the argument to %b, %c, or %s is to be
} interpreted as a string.

Just to clarify my earlier comment:

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.)
 
} If we had octal brace expansion, he could do something like
} printf "%b\n" \\0{101..145}

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?

I've just been looking at

  http://www.opengroup.org/onlinepubs/007904975/utilities/printf.html

I notice that although it mentions %b, there's NO definition of %b on any
of the pages it cross-references:

  http://www.opengroup.org/onlinepubs/007904975/basedefs/xbd_chap05.html
  http://www.opengroup.org/onlinepubs/007904975/functions/printf.html

Where is %b defined?

Re: printf for converting numbers to letters, bug?

[Clint Adams]

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

Solaris too.

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

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.

>   http://www.opengroup.org/onlinepubs/007904975/utilities/printf.html
> 
> I notice that although it mentions %b, there's NO definition of %b on any
> of the pages it cross-references:
> 
>   http://www.opengroup.org/onlinepubs/007904975/basedefs/xbd_chap05.html
>   http://www.opengroup.org/onlinepubs/007904975/functions/printf.html
> 
> Where is %b defined?

In #7 of EXTENDED DESCRIPTION of the first URL you cited.

Re: printf for converting numbers to letters, bug?

[Oliver Kiddle]

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