bug-coreutils
[Top][All Lists]
Advanced

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

bug#35046: [PATCH] factor: check the standard output instead of the stan


From: Pádraig Brady
Subject: bug#35046: [PATCH] factor: check the standard output instead of the standard input
Date: Sun, 31 Mar 2019 15:53:44 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0

On 30/03/19 22:14, Paul Eggert wrote:
> Pádraig Brady wrote:
>>> -        line_buffered = isatty (STDIN_FILENO);
>>> +        line_buffered = isatty (STDOUT_FILENO);
>>>         if (line_buffered)
>>>           lbuf_flush ();
>>>         else if (buffered >= FACTOR_PIPE_BUF)
>> That would impact use cases like:
>>
>>    factor | sed -u 's/.*: *//'
> 
> Sure, but the longstanding tradition for almost all GNU utilities is for 
> stdout 
> to be line-buffered if it is a tty (regardless of whether stdin is a tty), 
> and 
> that's how 'factor' behaved until we started fooling with buffering in 
> coreutils 
> 8.24. Shouldn't we simply go back to the longstanding tradition for deciding 
> whether to line-buffer stdout? Surely factor's current behavior is simply a 
> bug 
> introduced in 8.24 and not fixed in 8.26.

I should be clearer, sorry.

I think this could be improved.
I've pushed the change to set line_buffered if either stdin or stdout isatty():
https://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=6d78a28

I was wondering if there was a practical use case that this impacted.
Enough justification was provided in the commit message which I didn't read 
fully.

The original buffering adjustments were so that parallel invocations of factor,
output lines atomically, which factor is able to achieve given its restricted 
output format.

Marking this as done.

thanks,
Pádraig





reply via email to

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