[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: Chet Ramey
Subject: Re: Why does "mapfile -d delim" (delim != '\n') use unbuffered read?
Date: Tue, 4 May 2021 17:18:17 -0400
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.10.0

On 5/4/21 10:06 AM, Koichi Murase wrote:

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).

I used a combination of the simpler approach and the fstat/S_ISREG
strategy you suggested in your previous email.

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

I don't think this will make much of a difference -- it never has,
and the state of the file during the callback's execution isn't
defined -- but I made this change. Changing entrenched behavior is
always a tricky business. We'll see how it goes.

``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/

reply via email to

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