Stephane Chazelas wrote in
<20230902084912.vdfedsgbnat2w...@chazelas.org>:
|2023-09-01 23:28:50 +0200, Steffen Nurpmeso via austin-group-l at The \
|Open Group:
...
|>|FWIW, a "printf %b" github shell code search returns ~ 29k
|>|entries
2023-09-01 23:28:50 +0200, Steffen Nurpmeso via austin-group-l at The Open
Group:
[...]
> |FWIW, a "printf %b" github shell code search returns ~ 29k
> |entries
> |(https://github.com/search?q=printf+%25b+language%3AShell=code=Sh\
> |ell)
> |
> |That likely returns only a small subset of
Stephane Chazelas via austin-group-l at The Open Group wrote in
<20230901181024.pwx4plwclz7ij...@chazelas.org>:
|2023-09-01 07:54:02 -0500, Eric Blake via austin-group-l at The Open Group:
...
|> How many scripts in the wild actually use %b, though? And if there
|> are such scripts, anything
On Fri, Sep 1, 2023 at 8:10 PM Stephane Chazelas
wrote:
> 2023-09-01 07:54:02 -0500, Eric Blake via austin-group-l at The Open Group:
>
>
> FWIW, a "printf %b" github shell code search returns ~ 29k
> entries
> (
> https://github.com/search?q=printf+%25b+language%3AShell=code=Shell
> )
>
>
Ha
2023-09-01 07:54:02 -0500, Eric Blake via austin-group-l at The Open Group:
[...]
> > Well in all case %b can not change semantic in the bash script, since it is
> > there for so long, even if it depart from python, perl, libc, it is
> > unfortunate but that's the way it is, nobody want a semantic
If compatibility with C is really that important,
shouldn't we be fixing %c? Its current behaviour as a synonym for %.1s
doesn't provide significant utility, and arguably differs from C's "take an
int and output the corresponding single byte", not "take the first byte of
a string and output that".
2023-09-01 07:15:14 -0500, Eric Blake:
[...]
> > Note that in bash, you need both
> >
> > shopt -s xpg_echo
> > set -o posix
> >
> > To get a XSI echo. Without the latter, options are still
> > recognised. You can get a XSI echo without those options with:
> >
> > xsi_echo() {
> > local IFS='
On Fri, Sep 01, 2023 at 07:19:13AM +0200, Phi Debian wrote:
> Well after reading yet another thread regarding libc_printf() I got to
> admit that even %B is crossed out, (Yet already choosen by ksh93)
>
> The other thread also speak about libc_printf() documentting %# as
> undefined for things
On Fri, Sep 01, 2023 at 08:59:19AM +0100, Stephane Chazelas wrote:
> 2023-08-31 15:02:22 -0500, Eric Blake via austin-group-l at The Open Group:
> [...]
> > The current POSIX says that %b was added so that on a non-XSI
> > system, you could do:
> >
> > my_echo() {
> > printf %b\\n "$*"
> > }
>
2023-08-31 15:02:22 -0500, Eric Blake via austin-group-l at The Open Group:
[...]
> The current POSIX says that %b was added so that on a non-XSI
> system, you could do:
>
> my_echo() {
> printf %b\\n "$*"
> }
That is dependant on the current value of $IFS. You'd need:
xsi_echo() (
IFS=' '
2023-09-01 09:44:08 +0300, Oğuz via austin-group-l at The Open Group:
> On Fri, Sep 1, 2023 at 7:41 AM Phi Debian wrote:
> > My vote is for posix_printf %B mapping to libc_printf %b
>
> In the shell we already have bc for base conversion. Does POSIX really
> have to support C2x %b in the first
On Fri, Sep 1, 2023 at 7:41 AM Phi Debian wrote:
> My vote is for posix_printf %B mapping to libc_printf %b
In the shell we already have bc for base conversion. Does POSIX really
have to support C2x %b in the first place?
2023-09-01 07:13:36 +0100, Stephane Chazelas via austin-group-l at The Open
Group:
> 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
On Thu, Aug 31, 2023 at 9:11 PM Chet Ramey 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
Well after reading yet another thread regarding libc_printf() I got to
admit that even %B is crossed out, (Yet already choosen by ksh93)
The other thread also speak about libc_printf() documentting %# as
undefined for things other than a, A, e, E, f, F, g, and G, yet the same
thread also talk
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
On Thu, Aug 31, 2023 at 03:02:22PM -0500, Eric Blake wrote:
> On Thu, Aug 31, 2023 at 03:10:58PM -0400, Chet Ramey wrote:
> > 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
On Thu, Aug 31, 2023 at 03:10:58PM -0400, Chet Ramey wrote:
> On 8/31/23 11:35 AM, Eric Blake wrote:
> > 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
On 2023-08-31 08:35, Eric Blake wrote:
Typing-wise, %#s as a synonym for %b is
probably going to be easier (less shell escaping needed). Is there
any interest in a patch to coreutils or bash that would add such a
synonym, to make it easier to leave that functionality in place for
POSIX Issue 9
On 8/31/23 11:35 AM, Eric Blake wrote:
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
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).
For POSIX Issue 8, we plan to mark
21 matches
Mail list logo
