GNU bug report logs - #65659
RFC: changing printf(1) behavior on %b

Previous Next

Full log

View this message in rfc822 format

From: Phi Debian <phi.debian <at> gmail.com>
To: chet.ramey <at> case.edu
Cc: 65659 <at> debbugs.gnu.org, eblake <at> redhat.com, bug-bash <at> gnu.org, austin-group-l <at> opengroup.org
Subject: bug#65659: RFC: changing printf(1) behavior on %b
Date: Fri, 1 Sep 2023 06:40:54 +0200

[Message part 1 (text/plain, inline)]

On Thu, Aug 31, 2023 at 9:11 PM Chet Ramey <chet.ramey <at> case.edu> wrote:

>
> I doubt I'd ever remove %b, even in posix mode -- it's already been there
> for 25 years.
>
>
> Neither one is a very good choice, but `#' is the better one. It at least
> has a passing resemblence to the desired functionality.
>
> Why not standardize another character, like %B? I suppose I'll have to look
> at the etherpad for the discussion. I think that came up on the mailing
> list, but I can't remember the details.
>
>
Glad I red this thread before replying to the other one dealing with the
same issue.

I once worked on an issue on ksh93 regarding printf discrepency vs libc
printf, and got replied that "ksh is not C". I Think we got to admit that
shell's printf have departed from libc since long and now if a feature in
libc appears and collide with printf(1) then we got to get yet another %
exception char. In bash docco I see %b %q and %(datefmt...), so for a new
feature we should get something that we think libc as little chance to
target.

My vote is for posix_printf %B mapping to libc_printf %b, with the idea
that libc has little chance to have %B meaning UPPERCASE BINARY :-),  as %x
%X do.

And yet one more line in the docco explaining this divergence.

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.