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-512530360-1299017101=:10309
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 15:20, Tom Anderson wrote:
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.
Note that it looks like readline does not include the line delimiter
but explicitly include a new line.
Point being that on Windows it is still \n not \r\n.
I think it's more that there's a low-level layer that converts
platform-specific line endings to NL on the way in, and NL back to
platform-specific line endings on the way out. On top of that, readline()
includes the NL.
Now, who can point me at this atypical novel with count prefixes?
Docs or system or ... ?
A bookshop or ISBN number would do. Or is it actually Count Prefixes,
Dracula's Greek cousin?
tom
--
Sometimes it takes a madman like Iggy Pop before you can SEE the logic
really working.
--232016332-512530360-1299017101=:10309--