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

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

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

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 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

Re: Inner Command Lists fail in Bash 5.2.15

On Fri, 1 Sep 2023 12:52:14 -0400 Dima Korobskiy wrote: > Kerin, > > thanks for the workaround. > > Just to clarify, is the issue specific to the `time` command? I think that you would have to get an answer from Chet because yacc/bison grammar is a little over my head. To that end, I have

Re: give_terminal_to() / maybe_give_terminal_to() race

On 9/1/23 11:48 AM, Earl Chew wrote: What remains might be whether there is value in maintaining the present barrier in both parent and child so that it is straightforward to reason about designation of the foreground process in the controlling terminal. What makes the current implementation,

Re: give_terminal_to() / maybe_give_terminal_to() race

On 2023-09-01 04:58, Martin D Kealey wrote: On Fri, 1 Sep 2023, 15:51 Earl Chew, > wrote: The controlling terminal must be reconfigured before the parent gets to wait() for the job, and before the child gets to exec() the program (or their

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

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: RFC: changing printf(1) behavior on %b

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".

Re: Inner Command Groups fail in Bash 5.2

On Fri, 1 Sep 2023 10:29:29 -0400 Chet Ramey wrote: > On 9/1/23 10:27 AM, Kerin Millar wrote: > > > Would you mind supplying a diff for 5.2.15? For that version, I get: > > > > ./parse.y: In function ‘time_command_acceptable’: > > ./parse.y:3139:14: error: ‘DOLBRACE’ undeclared (first use in

Re: Inner Command Groups fail in Bash 5.2

On 9/1/23 10:27 AM, Kerin Millar wrote: Would you mind supplying a diff for 5.2.15? For that version, I get: ./parse.y: In function ‘time_command_acceptable’: ./parse.y:3139:14: error: ‘DOLBRACE’ undeclared (first use in this function); did you mean ‘Q_DOLBRACE’ Remove `DOLBRACE'. It's for

Re: Inner Command Groups fail in Bash 5.2

On Fri, 1 Sep 2023 09:52:17 -0400 Chet Ramey wrote: > On 8/31/23 1:21 PM, Dima Korobskiy wrote: > > > Bash Version: 5.2 > > Patch Level: 15 > > Release Status: release > > > > Description: > >     One of my Bash scripts started to fail all of a sudden and I was > > able to narrow down

Re: give_terminal_to() / maybe_give_terminal_to() race

On 9/1/23 7:58 AM, Martin D Kealey wrote: I would have though the obvious fix was to move setting tty pgrp into the child; this would guarantee that it happens before the execve() and before the waitpid() returns. Not quite; child processes already set the terminal pgrp. The question is

Re: give_terminal_to() / maybe_give_terminal_to() race

On 9/1/23 1:51 AM, Earl Chew wrote: On 2023-08-30 07:39, Chet Ramey wrote: I experimented a bit, and gave the matter some thought. The controlling terminal must be reconfigured before the parent gets to wait() for the job, Where do you get this requirement? Either the parent must yield

Re: [PATCH] printf: add %#s alias to %b

On 8/31/23 5:15 PM, Eric Blake wrote: It's not hard to see why POSIX is choosing to have Issue 8 obsoleting (not removing) %b's old semantics; in the short term, nothing about %b changes, so your dusty-deck shell scripts will continue to work as they have before; but you now have enough time

Re: Inner Command Groups fail in Bash 5.2

On 8/31/23 1:21 PM, Dima Korobskiy wrote: Bash Version: 5.2 Patch Level: 15 Release Status: release Description:     One of my Bash scripts started to fail all of a sudden and I was able to narrow down this problem to Bash upgrade itself (via Homebrew on a Mac): from 5.1.16 to 5.2.15.

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

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

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: give_terminal_to() / maybe_give_terminal_to() race

On Fri, 1 Sep 2023, 15:51 Earl Chew, wrote: > The controlling terminal must be reconfigured before the parent gets to > wait() for the job, and before the child gets to exec() the program (or their equivalents). This second point makes sense, but I don't really see why the first point is

Re: Fwd: Some incorrect behaviour for BASH arrays

On Fri, 1 Sep 2023 14:44:49 +0700 Victor Pasko wrote: > Just forward my response to all who was involved in discussion of my request > > -- Forwarded message - > From: Victor Pasko > Date: Fri, Sep 1, 2023 at 2:23 PM > Subject: Re: Some incorrect behaviour for BASH arrays > To:

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

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=' '

Fwd: Some incorrect behaviour for BASH arrays

Just forward my response to all who was involved in discussion of my request -- Forwarded message - From: Victor Pasko Date: Fri, Sep 1, 2023 at 2:23 PM Subject: Re: Some incorrect behaviour for BASH arrays To: Kerin Millar Thanks for the detailed explanations of *declare *.

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

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 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

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-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