I am using HP9000/800 HP-UX 10.20 and 11.00. In sh and ksh I have a problem using the /usr/bin/tail program. The problem seens to occur when tailing more than 207 lines on 11:00 or more than 381 on 10.20.
When executing (for example) a "tail -1000 textfile" command on a file containing for example 1711631 lines I only get 207 lines on the 11.00 server and 381 lines on the 10.20 server.
The manual doesn't say anything about limitations.
There is no such limitation for 'tail', especially when 'tailing' a few hundred files.
As the problem cause is most probably somewhere else, isn't the file located on an NFS filesystem. NFS is known to have a bug with "tail -f" which is solved by latest "NFS Kernel/Performance patch"
Best regards,
Dan
Everybody knows at least one thing worth sharing -- mailto:dan.hetzel@wildcroft.com
WARNINGS Tails relative to end-of-file are stored in a 20-Kbyte buffer, and thus are limited in length. Therefore, be wary of the results when piping output from other commands into tail.
The man page on tail states: WARNINGS Tails relative to end-of-file are stored in a 20-Kbyte buffer, and thus are limited in length. Therefore, be wary of the results when piping output from other commands into tail. Various kinds of anomalous behavior may occur with character special files.
Could use the following as a work-around ?
wc -l FILENAME # get total number of lines sed -n LINESTRART+1,LINEENDp SOURCEFILE > DESTINATIONFILE
The buffer limit in tail is something that should've been fixed a long time ago. The GNU tail probably does it the right way.
Failing that, here's a simple way to use awk to do a 'tail -n###' without the buffer limitation of the tail command:
awk 'NR >= ###' filename
The awk special variable 'NR' is the record number (i.e. line number). The '###' is the line number you want to start at. Since there's no action defined, the default action of '{print}' is used.
