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.
