printf(1) %c doesn't work as expected, instead like %.1s.

[Ralph Corderoy]

Binary package hint: coreutils

Ubuntu 7.10, coreutils 5.97-5.3ubuntu3.

coreutils' printf(1) and bash(1)'s built-in printf don't handle `%c'
in the expected way. Instead, it treats it as `%.1s'.

    $ type printf
    printf is a shell builtin
    $ /usr/bin/printf %c 65
    6$
    $ printf %c 65
    6$
    $ /usr/bin/printf %.1s 65
    6$
    $ awk 'BEGIN {printf("%c", 65)}' </dev/null
    A$
    $

C, awk, Python, Perl, etc., all work as expected. As it stands, there's
no easy way of turning $foo containing "65" into "A". printf(1) does
accept

    $ printf \\x41
    A$
    $

but that's not the same thing.

As with %d, printf(1) should turn the string argument "65" into an
integer before passing to printf(3).

[John Vivirito (gnomefreak)]

I am able to confirm this on Intrepid and Hardy

gnomefreak@Development:~$ type printf
printf is a shell builtin
gnomefreak@Development:~$ /usr/bin/printf %c 65
6gnomefreak@Development:~$ printf %c 65
6gnomefreak@Development:~$
awk 'BEGIN {printf("%c", 65)}' </dev/null
Agnomefreak@Development:~$

gnomefreak@Development:~$ printf \\x41
Agnomefreak@Development:~$

[John Vivirito (gnomefreak)]

gnomefreak@Development:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu intrepid (development branch)
Release: 8.10
Codename: intrepid

coreutils:6.10-3ubuntu2

[C de-Avillez (hggdh2)]

I looked up this on the coreutils mailing list (the nearer they have to a BTS, and there is this entry: http://lists.gnu.org/archive/html/bug-coreutils/2006-01/msg00070.html about this behaviour:

"Update of patch #3286 (project coreutils):

                  Status: None => Invalid

    _______________________________________________________

Follow-up Comment #1:

POSIX requires the current behavior, where the argument that matches up to %c
is treated as a string and the first character of that string is printed. So,
unfortunately, your patch cannot be accepted without violating POSIX semantics
for printf(1). What would be useful, however, is a documentation patch that
makes this behavior clear in both the info pages and the --help output (right
now, the info pages assume that you already know how printf(3) works, which is
not as useful as it could be; and fails to mention that %c parses its argument
as a string and not a C constant integer). I'm leaving this patch open as a
reminder that a doc patch is needed."

So it seems what is really needed is to update the documentation.