Re: Reading LAST line from text file without iterating through the
file?
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
--232016332-1166670890-1298838007=:3615
Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8BIT
On Sun, 27 Feb 2011, Arne Vajh??j wrote:
On 27-02-2011 09:59, Ken Wesson wrote:
On Sat, 26 Feb 2011 16:44:43 -0500, Arne Vajh??j wrote:
On 26-02-2011 06:15, Ken Wesson wrote:
On Fri, 25 Feb 2011 14:58:27 +0000, Martin Gregorie wrote:
a text file contains records. They are variable length records with a
'newline' encoding as the delimiter.
By that definition the concept of "record-based" vs. "not-record-based"
becomes completely meaningless.
But most of us use "records" to mean a structure that involves out-of-
band boundaries of some sort. Linear text with inline line break etc.
characters has only in-band boundaries and is much less structured than
what a "record" typically implies.
A line is by definition a structure because there is something that
determines where it starts and where it ends.
But it's entirely in-band structure. Line breaks are a natural part of
texts.
Neither a count prefix or the the line delimiter are part of the line
itself.
But you're looking at the wrong unit of granularity here. A line
delimiter is part of the *text* itself. But a count prefix is not. Read a
page of a novel. You will notice many line breaks, but no count prefixes,
if your selection was at all typical.
I suggest you look at Java BufferedReader readLine, Pascal readln etc. -
they do not return the line break as part of the line.
Oddly, Pythons's file.readline() does. I believe it's so that readline()
is the inverse of write(), which does not add a line terminator. You might
think that it would be more sensible that readline() should strip the
terminator, and that there should be a writeline() that adds one, but
that's not how it is.
Now, who can point me at this atypical novel with count prefixes?
tom
--
Everything looks kind of OK
--232016332-1166670890-1298838007=:3615--