Re: heap-buffer-overflow in history_expand

2023-05-25 Thread Grisha Levit
On Mon, May 1, 2023 at 11:48 AM Chet Ramey wrote: > Yes, I concluded the same thing. Thanks for the patch. I have one question > about the change to rl_insert: why overwrite any return value from the > initial call to _rl_insert_char by setting r back to 0? What if the initial > value of C starts

Re: "environment:" instead of $0 in front of fatal errors from functions

2023-05-25 Thread Chet Ramey
On 5/22/23 8:36 AM, Emanuele Torre wrote: Error messages for fatal error e.g. ${x?foo} or rovar=foo or $x expanded with nounset, report an error message prefixed by the string "environment:" instead of "scriptname:" (or "$0:"). Thanks for the report. Error messages during function

Re: nofork command substitution

2023-05-25 Thread Daniel Douglas
These are both very useful!

Re: nofork command substitution

2023-05-25 Thread Chet Ramey
On 5/25/23 1:19 PM, Robert Elz wrote: Date:Thu, 25 May 2023 10:17:01 -0400 From:Chet Ramey Message-ID: | a nofork command substitution is | '${' compound_list '}', you omitted the extra char there, not that it matters for the purpose here. It's part

Re: nofork command substitution

2023-05-25 Thread Robert Elz
Date:Thu, 25 May 2023 10:17:01 -0400 From:Chet Ramey Message-ID: | a nofork command substitution is | '${' compound_list '}', you omitted the extra char there, not that it matters for the purpose here. | The difference, as you say, is | that a command

Re: nofork command substitution

2023-05-25 Thread Chet Ramey
On 5/25/23 8:13 AM, Robert Elz wrote: Note that ${C } is not a group - it is syntax that delimits a command substituition in a word, and what's in a command substitution is a list (which can contain groups, or be one, but isn't required to be). There's not any real difference. A group command

Re: nofork command substitution

2023-05-25 Thread Chet Ramey
On 5/25/23 6:29 AM, Koichi Murase wrote: 2023年5月24日(水) 22:27 Chet Ramey : [...] Thanks for testing it. Thank you for all the explanations and clarifications. Both are valid, but don't get too fond of ${(command)} -- I'm going to remove it in favor of people using ${ (command); } if they

Re: Unset during expansion w/ nofork sub

2023-05-25 Thread Chet Ramey
On 5/24/23 9:45 AM, Grisha Levit wrote: There are a lot of code paths that (reasonably) do not expect a variable to disappear while being expanded/assigned to, and usually cause a segfault if that happens (as is now possible with the new nofork command substitution). I don't think there is any

Re: nofork command substitution

2023-05-25 Thread Koichi Murase
2023年5月25日(木) 21:13 Robert Elz : > | Does that mean ${(command)} would be explicitly unsupported even > | though {(command)} is allowed for the brace grouping? > > The two are mostly unrelated. Yes, they are independent, but there is still a "choice" to make the new grammar similar to the

Re: text similar to JSON can cause memory of bash to become abnormally large

2023-05-25 Thread Chet Ramey
On 5/24/23 9:39 PM, wang yuhang via Bug reports for the GNU Bourne Again SHell wrote: hi I accidentally copied a section of JSON text to the terminal and executed it, which resulted in a system crash.Bash version is 5.1.8. Later, I reproduced it and found that when I executed the following

Re: nofork command substitution

2023-05-25 Thread Robert Elz
Date:Thu, 25 May 2023 19:29:40 +0900 From:Koichi Murase Message-ID: | Does that mean ${(command)} would be explicitly unsupported even | though {(command)} is allowed for the brace grouping? The two are mostly unrelated. | Would other cases without

Re: With DEBUG trap, resizing window crashes script

2023-05-25 Thread L A Walsh
On 2023/05/10 13:13, Eduardo Bustamante wrote: If you wish for the current shell to continue running after a terminal resize, then set the signal disposition for SIGWINCH to ignore. --- You can also display the new size: alias my=declare showsize () {\ my s=$(stty size); s="(${s// /x})"

Re: nofork command substitution

2023-05-25 Thread Koichi Murase
2023年5月24日(水) 22:27 Chet Ramey : > > [...] > > Thanks for testing it. Thank you for all the explanations and clarifications. > Both are valid, but don't get too fond of ${(command)} -- I'm going to > remove it in favor of people using ${ (command); } if they want a subshell. Does that mean