Re: Why does "mapfile -d delim" (delim != '\n') use unbuffered read?

2021年5月4日(火) 3:40 Chet Ramey : > On 5/3/21 10:14 AM, Chet Ramey wrote: > >> This treatment of `mapfile' for "delim != '\n'" exists since the > >> mapfile delimiter is first introduced by commit 25a0eacfe "commit > >> bash-20140625 snapshot". Would it be a problem to change to the > >> buffered

Re: Why does "mapfile -d delim" (delim != '\n') use unbuffered read?

On 5/3/21 10:14 AM, Chet Ramey wrote: This treatment of `mapfile' for "delim != '\n'" exists since the mapfile delimiter is first introduced by commit 25a0eacfe "commit bash-20140625 snapshot". Would it be a problem to change to the buffered read also for non-LF delimiters? If we could remove

Re: Why does "mapfile -d delim" (delim != '\n') use unbuffered read?

On 5/2/21 9:51 AM, Koichi Murase wrote: Maybe I'm asking a stupid question, but, as in the subject, why does the builtin "mapfile -d delim" use unbuffered read when delim != '\n'? It's the shell being careful in the general case. You need to guarantee behavior in all of the cases where read(2)

Re: Memory leak in function with local array

On 5/2/21 8:19 AM, thomas.gren...@aalto.fi wrote: Bash Version: 5.1 Patch Level: 4 Release Status: release Description: There seems to be a memory leak in bash when a local array is declared within a function. I also tested this on "GNU bash, version 5.0.17(1)-release