Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!julius.cs.uiuc.edu!apple!olivea!tymix!cirrusl!sunstorm!dhesi From: dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) Newsgroups: comp.unix.wizards Subject: Re: Need efficient way to read file in reverse Message-ID: <2505@cirrusl.UUCP> Date: 26 Sep 90 03:43:07 GMT References: <1990Sep18.152818.1303@phri.nyu.edu> <11217@celit.fps.com> Sender: news@cirrusl.UUCP Organization: Cirrus Logic Inc. Lines: 33 The question from Roy Smith was: Is there a standard, portable, efficient way to read a file in reverse? The word "portable" is the catch here. There is *no* truly portable way to seek to a place in a file where you haven't been before. Worse, there is *no* truly portable way to seek to *any* place in a text file whether or not you have been there before. (I'm sure some people will protest at the second claim and mention magic cookies, but they may be assuming that "portable" means "ANSI-conformant". This is not a portable assumption :-) Since this is a comp.unix.* discussion, however, we may be able to modify the meaning of "portable" somewhat by restricting ourselves to solutions that work in a **IX environment. In <11217@celit.fps.com> hutch@fps.com (Jim Hutchison) writes: >The ideal block size for reading your file can be gotten by doing a stat() or >fstat() on it, and using stat->st_blksize (see stat(2)). If you setbuffer() >with a buffer that size, you should have a quasi-optimal block size. Alas, neither stat->st_blksize nor setbuffer() are universally available, not even in a **IX environment. You may need to use setvbuf() instead, which itself isn't universally available. Modifying the meaning of "portable" still further, perhaps we could settle for it to mean "works under 4.3BSD and System V Release 4". Now you're talking! -- Rahul Dhesi UUCP: oliveb!cirrusl!dhesi