Tshepang Lekhonkhobe wrote: > even by default, it not longer waits for a second, but is more like > 'real-time'
I don't understand your comment in a bug report. Being more responsive seems like a good thing to me and good expected behavior. Could you say a few words about why you are filing a bug report on tail being more responsive? See the /usr/share/doc/coreutils/News.gz file for a list of newsworthy changes to tail. In coreutils tail 7.5 tail aquired the ability to use inotify. tail --follow now uses inotify when possible, to be more responsive to file changes and more efficient when monitoring many files. Between versions 7.5 and 8.3 a period of instability resulted where many bugs against tail's new behavior was reported. (Newest on top.) tail -f (inotify-enabled) once again works with remote files. The use of inotify with remote files meant that any changes to those files that was not done from the local system would go unnoticed. [bug introduced in coreutils-7.5] tail -F (inotify-enabled) would abort when a tailed file is repeatedly renamed-aside and then recreated. [bug introduced in coreutils-7.5] tail -F (inotify-enabled) could fail to follow renamed files. E.g., given a "tail -F a b" process, running "mv a b" would make tail stop tracking additions to "b". [bug introduced in coreutils-7.5] tail without -f no longer access uninitialized memory [bug introduced in coreutils-7.6] tail -f (inotify-enabled) now avoids a race condition. Before, any data appended in the tiny interval between the initial read-to-EOF and the inotify watch initialization would be ignored initially (until more data was appended), or forever, if the file were first renamed or unlinked or never modified. [The race was introduced in coreutils-7.5] tail -F (inotify-enabled) now consistently tails a file that has been replaced via renaming. That operation provokes either of two sequences of inotify events. The less common sequence is now handled as well. [The bug came with the implementation change in coreutils-7.5] tail --follow --pid now avoids a race condition where data written just before the process dies might not have been output by tail. Also, tail no longer delays at all when the specified pid is not live. [The race was introduced in coreutils-7.5, and the unnecessary delay was present since textutils-1.22o] tail -f (inotify-enabled) now flushes any initial output before blocking. Before, this would print nothing and wait: stdbuf -o 4K tail -f /etc/passwd Note that this bug affects tail -f only when its standard output is buffered, which is relatively unusual. [bug introduced in coreutils-7.5] tail -f once again works with standard input. inotify-enabled tail -f would fail when operating on a nameless stdin. I.e., tail -f < /etc/passwd would say "tail: cannot watch `-': No such file or directory", yet the relatively baroque tail -f /dev/stdin < /etc/passwd would work. Now, the offending usage causes tail to revert to its conventional sleep-based (I.e., not inotify-based) implementation. [bug introduced in coreutils-7.5] tail -f now ignores "-" when stdin is a pipe or FIFO. tail-with-no-args now ignores -f unconditionally when stdin is a pipe or FIFO. Before, it would ignore -f only when no file argument was specified, and then only when POSIXLY_CORRECT was set. Now, :|tail -f - terminates immediately. Before, it would block indefinitely. It seems to have settled down now and is back to functioning acceptably for people again. Bob -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
