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 Brought to you by Super Global Mega Corp .com