[Top][All Lists]

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

bug#32228: sed -i does not buffer, causing excessive writes

From: Jim Meyering
Subject: bug#32228: sed -i does not buffer, causing excessive writes
Date: Thu, 2 Aug 2018 16:40:38 +0200

On Sat, Jul 21, 2018 at 3:48 AM, Assaf Gordon <address@hidden> wrote:
> Hello,
> On 20/07/18 02:23 PM, Vidar Holen wrote:
>> I'm using noticing that `sed -i` does not do any kind of output
>> buffering. While behavior is correct, this causes an excessive number of
>> small writes:
>> I'm seeing this on Debian with the latest sed commit (c52a676) and libc
>> 2.27-2. The root cause appears to be `ck_mkstemp` using `fdopen`, which
>> unlike `fopen` does not buffer by default.
> Thank you for reporting this issue, and providing clear way to reproduce
> it. I can confirm seeing the same behavior on Debian 9.4 with glibc 2.24
> (and latest sed).
> I think the technical culprit is slightly different:
> It is not due to 'ck_mkstemp/fdopen', but because sed explicitly flushes
> the output after every line, except if the output is STDOUT.
> This happens in execute.c:flush_output():
> https://opengrok.housegordon.com/source/xref/sed/sed/execute.c#flush_output
> Changing this function enables default buffering with "sed -i"
> (using whatever the buffering default is for glibc).
> This change does have a side-effect:
> It also changes the buffering of other write commands such as 'w', 'W'
> and 's///w'.
> It might have other side effects I'm haven't spotted.
> Based on the ChangeLog-2014 file, I see this function was added in 2003.
> I wonder if there are good reasons to explicitly flush all output -
> ideas anyone?

Thank you, Assaf. This change looks fine.
I too tried to determine why that code was written that way to no
avail. I have no idea what the motivation might have been.

reply via email to

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