[Top][All Lists]

[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'".


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]