Re: bash 5.1 heredoc pipes problematic, shopt needed

[Alexey]

Hello.

On 2022-04-28 20:56, Greg Wooledge wrote:
> Second, none of your examples work with arbitrary filenames, which may
> contain newline characters.  The solution to that is to use find 
> -print0
> and to read the NUL-delimited stream in the shell.
I want to assure you (and others) that my point was not in safe usage of 
`find' (with null-terminated strings),
or any other shell tricks and best practice.

Also, it doesn't matter how long `find' took because it's called only 
one time in each example, but
examples working time differs several times. So when we are talking 
about not "how much more" but
"how many times" time spent in single command which used in each example 
doesn't affect result.

I didn't consider process substitution "< <()" in first example because 
it's always slower since use 1-byte read().
And also I mentioned that in most cases we have to use 
process-substitution instead of here-string because of newline.

> >    Bash could do 4096b read() to some internal buffer related to
> > file-descriptor and have an emulated lseek()
> >    within that buffer.
>
> That would only fix the case where the rest of the input is supposed to
> be processed by bash.  It would *not* fix the common case where bash is
> reading a little bit of the stream, and then executing another program
> to read the remainder of the stream.  For the second program, some of
> its data has already been consumed.

Yes, this buffer should be used only when read/readarray will get 
special option,
I told, that only script-writer could know will "this" descriptor be 
used somewhere else or not.

Regards,
Alexey.