[Top][All Lists]

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

[debbugs-tracker] bug#13498: closed ("cut -f" lags a line)

From: GNU bug Tracking System
Subject: [debbugs-tracker] bug#13498: closed ("cut -f" lags a line)
Date: Tue, 22 Jan 2013 02:40:01 +0000

Your message dated Tue, 22 Jan 2013 02:37:54 +0000
with message-id <address@hidden>
and subject line Re: bug#13498: "cut -f" lags a line
has caused the debbugs.gnu.org bug report #13498,
regarding "cut -f" lags a line
to be marked as done.

(If you believe you have received this mail in error, please contact

13498: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13498
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- Subject: "cut -f" lags a line Date: Sat, 19 Jan 2013 00:35:18 -0800
"cut -f" has an apparently long-standing behavior that I'd consider a
bug: it does not fully send line N to stdout until the first character
of line N+1 has been read on stdin. This is confusing when stdin comes
from "tail -f" or the like. The exact behavior varies slightly. If
stdin is a tty, all but the trailing newline will be flushed
immediately and then the trailing newline will be flushed when the
next character shows up. If stdin is not a tty, there's no flush at
all until the next character shows up.

For example, if I type the following into a shell on Ubuntu 12.04.1,
meaning cut from coreutils 8.13 and glibc package version

    cut -f1-

I will see the following:

    $ cut -f1-



and if I instead use "cat | cut -f1-" in the first line, I will see
the following:

    $ cat | cut -f1-

(coreutils's cut -c does not have the same laggy behavior. Neither
does BSD cut on my OS X machine in either -c or -f mode.)

This code in cut_fields (still found in trunk tip) is responsible for
delaying the newline; it runs between the newline being read and being

      if (c == '\n')
          c = getc (stream);
          if (c != EOF)
              ungetc (c, stream);
              c = '\n';

I believe that code is there to avoid turning one newline at EOF into
two, but that goal could be accomplished in another way.

I don't know exactly why the behavior differs based on stdin being a
tty or not. My best guess is that glibc might have some logic that, if
stdin is a tty, automatically flushes stdout any time the program
blocks on stdin. glibc's stdio internals are a bit hard for me to
follow, so I haven't found the code in question. Apparently this is a
vaguely standardized behavior; I see a stackoverflow post mentioning
the following:

The input and output dynamics of interactive devices shall take place
as specified in 7.19.3. The intent of these requirements is that
unbuffered or line-buffered output appear as soon as possible, to
ensure that prompting messages actually appear prior to a program
waiting for input.

(ISO/IEC 9899:TC2 Committee Draft -- May 6, 2005, page 14).

Scott Lamb <http://www.slamb.org/>

--- End Message ---
--- Begin Message --- Subject: Re: bug#13498: "cut -f" lags a line Date: Tue, 22 Jan 2013 02:37:54 +0000 User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1
Proposed patch at: 

--- End Message ---

reply via email to

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