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

2023-09-08 Thread Chet Ramey via austin-group-l at The Open Group
On 9/3/23 2:36 AM, Stephane Chazelas via austin-group-l at The Open Group wrote: And except with yash's printf (among the few printf's I've tested): $ LC_ALL=zh_TW luit $ locale title charmap Chinese locale for Taiwan R.O.C. BIG5 $ echo() { printf '%b ' "$@"\\n\\c; } $ echo 'α' αn% (the

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

2023-09-05 Thread Chet Ramey via austin-group-l at The Open Group
On 9/3/23 4:22 PM, Robert Elz via austin-group-l at The Open Group wrote: Date:Sun, 3 Sep 2023 07:36:59 +0100 From:Stephane Chazelas Message-ID: <20230903063659.mzyfen4evyrnz...@chazelas.org> | though has the same limitation as my bash echo -e "$*\n\c" Yes,

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

2023-09-03 Thread Robert Elz via austin-group-l at The Open Group
Date:Sun, 3 Sep 2023 07:36:59 +0100 From:Stephane Chazelas Message-ID: <20230903063659.mzyfen4evyrnz...@chazelas.org> | though has the same limitation as my bash echo -e "$*\n\c" Yes, I know, though as nothing anywhere says what echo is supposed to do with a lone

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

2023-09-03 Thread Stephane Chazelas via austin-group-l at The Open Group
2023-09-03 08:27:58 +0700, Robert Elz via austin-group-l at The Open Group: [...] > The SysIII echo (abomination) can be done using printf %b independant > of IFS: > > echo() { printf '%b ' "$@"\\n\\c; } > > works. Nice, though has the same limitation as my bash echo -e "$*\n\c" $ echo()

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

2023-09-02 Thread Robert Elz via austin-group-l at The Open Group
Date:Fri, 1 Sep 2023 07:15:14 -0500 From:"Eric Blake via austin-group-l at The Open Group" Message-ID: | > That is dependant on the current value of $IFS. You'd need: | > | > xsi_echo() ( | > IFS=' ' | > printf '%b\n' "$*" | > ) | | So yes,

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

2023-09-02 Thread Steffen Nurpmeso via austin-group-l at The Open Group
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

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

2023-09-02 Thread Stephane Chazelas via austin-group-l at The Open Group
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

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

2023-09-01 Thread Steffen Nurpmeso via austin-group-l at The Open Group
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

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

2023-09-01 Thread Stephane Chazelas via austin-group-l at The Open Group
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

Fwd: Re: RFC: changing printf(1) behavior on %b

2023-09-01 Thread Steffen Nurpmeso via austin-group-l at The Open Group
oup-l at The Open Group" Cc: Phi Debian , chet.ra...@case.edu, Eric Blake , bug-coreut...@gnu.org, bug-b...@gnu.org, Steffen Nurpmeso Subject: Re: RFC: changing printf(1) behavior on %b Message-ID: <20230901163434._byqv%stef...@sdaoden.eu> Mail-Followup-To: "Oğuz via austin-group-l at T

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

2023-09-01 Thread Stephane Chazelas via austin-group-l at The Open Group
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='

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

2023-09-01 Thread Eric Blake via austin-group-l at The Open Group
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

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

2023-09-01 Thread Eric Blake via austin-group-l at The Open Group
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 "$*" > > } >

Re: RFC: changing printf(1) behavior on %b

2023-09-01 Thread Oğuz via austin-group-l at The Open Group
On Fri, Sep 1, 2023 at 10:12 AM Stephane Chazelas wrote: > Yes, though note: > > - that implies forking a process and loading an external > executable and its libraries The standard doesn't mandate that printf be a builtin; so, in principle, this might be the case with printf as well. > - bc

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

2023-09-01 Thread Stephane Chazelas via austin-group-l at The Open Group
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=' '

Re: RFC: changing printf(1) behavior on %b

2023-09-01 Thread Stephane Chazelas via austin-group-l at The Open Group
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

Re: RFC: changing printf(1) behavior on %b

2023-09-01 Thread Stephane Chazelas via austin-group-l at The Open Group
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

Re: RFC: changing printf(1) behavior on %b

2023-09-01 Thread 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 place?

Re: RFC: changing printf(1) behavior on %b

2023-09-01 Thread 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 similar to XSI > echo) that will eventually conflict with C2x's desire to introduce %b > to

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

2023-08-31 Thread Eric Blake via austin-group-l at The Open Group
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

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

2023-08-31 Thread Paul Eggert via austin-group-l at The Open Group
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

Re: RFC: changing printf(1) behavior on %b

2023-08-31 Thread Chet Ramey via austin-group-l at The Open Group
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

RFC: changing printf(1) behavior on %b

2023-08-31 Thread 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). For POSIX Issue 8, we plan to mark