bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Koichi Murase
Subject: Re: Why does "mapfile -d delim" (delim != '\n') use unbuffered read?
Date: Tue, 4 May 2021 23:06:11 +0900

2021年5月4日(火) 22:28 Chet Ramey <chet.ramey@case.edu>:
> On 5/4/21 2:31 AM, Koichi Murase wrote:
> > (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.
> >
> > [...]
> >
> > lseek(2) may succeed on non-seekable streams including some terminal
> > device (mentioned in Chet's reply) and a tape device (mentioned in the
> > above FreeBSD discussion).
>
> Let's take a step back. I think we can make the code simpler and still
> handle all the cases we need to. I don't think tape devices are worth
> worrying about.
>
> The issue with the BSDs and terminal devices is that the current code
> only checks for -1/ESPIPE, but they return a different value for errno
> (EINVAL? I forget.) I believe AIX returns something else. Rather than
> check for specific errno values, we can just decide not to buffer input
> if lseek fails for any reason.

OK.  I agree with this direction.  The attached file is my current
patch for (2) and (3) with the above strategy (no check for ESPIPE).

----

By the way, I'm sorry but there was a typo in my previous mail:

> (3) Suggestion: change the order of `run_callback' and `zsyncfd'?
>
> I noticed that `zsyncfd' is called before `run_callback':

This is a typo of "`zsyncfd' is called **after** `run_callback'".

--
Koichi

Attachment: 0001-mapfile-buffered-read-in-more-cases-v2.patch
Description: Binary data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]