I'm still thinking about whether it is possible to use buffered read
in more cases of mapfile.
(1) Suggestion: use buffered read for a regular file for delim != '\n'?
> It won't work on any system that doesn't return -1/ESPIPE when you try
> to lseek on a terminal device.
I found a related inter
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 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
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)
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
(x86_64-redhat
