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

[Koichi Murase]

2021年5月4日(火) 3:40 Chet Ramey <chet.ramey@case.edu>:
> 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 the above
> >> two lines (i.e., if (delim != '\n') unbuffered_read = 1;), I'd be very
> >> happy...
> >
> > Try it out and see.

Actually, I had tried it with my Linux before I sent my previous mail,
and it seemed to work without problems. But I was not sure if it works
in every situation so asked the question.

> I should have mentioned up front that this will not work in the general
> case on at least macOS, the BSDs, and (I believe) AIX.
>
> It won't work on any system that doesn't return -1/ESPIPE when you try
> to lseek on a terminal device. Glibc does; the above systems don't;
> POSIX makes the behavior undefined.

Oh, I see. Thank you for the explanation. I was somehow assuming that
seekable file descriptors can be always correctly detected by the
previous lines (builtins/mapfile.def L188).  Can we check __GLIBC__ to
detect glibc lseek and safely skip the check on the delimiter?
Something like

#ifndef __GLIBC__
  /* Use the buffered read only when the delimiter is a newline because
     unseekable fd's may not be detected by non-glibc lseek(2). */
  if (delim != '\n')
    unbuffered_read = 1;
#endif

Thank you,
Koichi