bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#65659: RFC: changing printf(1) behavior on %b


From: Stephane Chazelas
Subject: bug#65659: RFC: changing printf(1) behavior on %b
Date: Fri, 1 Sep 2023 07:13:36 +0100

2023-08-31 10:35:59 -0500, Eric Blake via austin-group-l at The Open Group:
> In today's Austin Group call, we discussed the fact that printf(1) has
> mandated behavior for %b (escape sequence processing similar to XSI
> echo) that will eventually conflict with C2x's desire to introduce %b
> to printf(3) (to produce 0b000... binary literals).
[...]

Is C2x's %b already set in stone?

ksh93's printf (and I'd  expect ast's standalone printf) has
%<width>[,<precision>[,<base>]d to output a number in an
arbitrary base which IMO seems like a better approach than
introducing a new specifier for every base.

$ printf '%..2d\n' 63
111111
$ printf '0b%.8.2d\n' 63
0b00111111
$ printf '%#.8.2d\n' 63
2#00111111

The one thing it can't do though is left-space-padding of 0b1111.

printf %b is used in countless scripts especially the more
correct/portable ones that use it to work around the portability
fiasco that is echo's escape sequence expansion. I can't imagine
it going away. Hard to imagine the C folks overlooked it, I'd
expect printf %b to be known by any shell scripter.

-- 
Stephane





reply via email to

[Prev in Thread] Current Thread [Next in Thread]