Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: Notesfiles $Revision: 1.7.0.8 $; site infoswx
Path: utzoo!watmath!clyde!cbosgd!ihnp4!inuxc!pur-ee!uiucdcs!convex!infoswx!bees
From: bees@infoswx.UUCP
Newsgroups: net.sources
Subject: Re: Orphaned Response
Message-ID: <11100002@infoswx>
Date: Mon, 30-Sep-85 13:00:00 EDT
Article-I.D.: infoswx.11100002
Posted: Mon Sep 30 13:00:00 1985
Date-Received: Fri, 4-Oct-85 03:29:30 EDT
References: <351@link.UUCP>
Lines: 26
Nf-ID: #R:link.UUCP:-35100:infoswx:11100002:000:911
Nf-From: infoswx.UUCP!bees    Sep 30 12:00:00 1985


>In article <11100001@infoswx> bees@infoswx.UUCP writes:
>>Not to mention:
>>			tail -r file
>>assuming 4bsd...
>
>Yes, except that it will only list the last 4 k (or so) of the
>file - so 
>	revfile != tail -r
>Of course, the right approach would be to replace the -r code in
>tail with the revfile code.
>
>------------------
>Kim F. Storm, Inst of Datalogy(=CS), U of Copenhagen, Sigurdsgade 41, DK-2200 N
>UUCP: mcvax!diku!storm,            tel: +45 1 83 64 66, ext 14

Quite right!  I knew that there was a 4k limit to the size of any tail(1)
operation.  I recently wrote a program to "prune" (truncate the top) log
files that grow to infinity, because "tail -100b" never works.

Another approach would be to fix tail such that it dynamically allocates
memory, instead of limiting things to a 4k internal buffer.

Ray Davis
Teknekron Infoswitch, Richardson, TX
infoswx!bees, (214)644-0570