[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: RFC: changing printf(1) behavior on %b
From: |
Stephane Chazelas |
Subject: |
Re: 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
- Re: RFC: changing printf(1) behavior on %b, (continued)
Re: RFC: changing printf(1) behavior on %b, Oğuz, 2023/09/01
Re: RFC: changing printf(1) behavior on %b,
Stephane Chazelas <=
Re: RFC: changing printf(1) behavior on %b, Martin D Kealey, 2023/09/01