Reading LAST line from text file without iterating through the file?

[Jim Janney]

Please shut up.

http://www.catb.org/~esr/faqs/smart-questions.html#not_losing

 

[Daniele Futtorovic]

No, I'm sure your Usenet provider correctly indicated that I said "it's
not your grandfather's ASCII" and you then altered the quotation.


Your personal opinions of others are not the topic of this newsgroup. Do
you have anything Java-related to say?


Your personal opinions of others are not the topic of this newsgroup. Do
you have anything Java-related to say?

Sigh.

*PLONK*

 

[Arne Vajhøj]

*sigh*

Will you people give it a FUCKING REST ALREADY?

Sheesh!

You've made your "point" (such as it is) already; there is no need for
endless carping repetitions of your *opinions*.

Have you considered taking your own advice??

Arne

 

[Arne Vajhøj]

So you claim.

You can easily verify be checking phones from the big
producers like Nokia.

But even if there was some truth to that claim, where would
your typical user *get* these apps?

Via the phones browser and HTTP from any web server.

(or cable or Bluetooth if that should be preferred)

Arne

 

[Andreas Leitgeb]

In this forum people all the time try to make the claim that an OP meant
something not in the original post. For example, the other thread where the
OP asked how to produce a 'List <String1>' and everyone (except me) assumed
and argued that they *must* have meant 'List <String>', even though they took
great pains not to say so.

In this forum, people assume, that questions asked here do not necessarily
have to be of reviewed-problem-specification quality to deserve an answer.

So, if a question asked here seems to imply really odd points and does not
explicitly indicate that it is really meant to do so, then it's just more
likely that it wasn't meant so.

If the answer depends on further clarification, there is no problem making
assumptions about those. If it turns out to be a wrong interpretation of the
question or a wrong assumption... So what? 10 minutes wasted, but no harm done.
The typical intention is to help, not to answer questions literally.

If you prefer to answer questions literally, then by all means do so, for the
chance that they were actually reviewed-problem-specifications isn't 0, after
all. Just don't be overly exasperated by others following different strategies
meant to help the questioner.

 

[Arne Vajhøj]

[...]
Better googling skills bark bark bark bark bark!

Bark bark bark bark bark bark bark bark bark!

If you jump up at me, I will take action to defend myself, and I
outmass all terriers by *at least* a factor of 20 to 1, so you *will*
get the raw end of it!

Bark bark bark bark bark bark bark bark bark bark bark bark bark bark
bark bark bark bark bark bark bark bark bark!

Bark bark bark bark bark bark bark bark bark bark bark bark bark bark
bark bark!

Bark bark bark bark bark bark bark bark bark bark bark bark bark bark
bark bark bark bark bark bark bark bark bark bark bark bark bark bark
bark bark bark bark bark bark bark bark bark bark bark bark bark bark
bark bark bark bark bark bark bark bark bark bark bark bark
bark bark bark bark bark bark bark bark bark bark bark bark bark bark
bark bark bark bark bark bark bark bark!

Bark!

Just how many fucking yappers ARE there around here anyway? Are there
actually any *human beings*, aside from myself, that are actually capable
of engaging in civil discourse and even sometimes disagreeing with what
somebody says *without* turning it into a personal fight full of barks,
growls, name-calling, and general hystrionics of a most unseemly nature?

I am pretty sure that you are the only one writing "bark".

Arne

 

[Arne Vajhøj]

Evasion noted. But people don't use i to play games or fileshare or run
web services, which are the most usual places I see Java being used. They
play Java games on Java phones and Windows, fileshare with Limewire on
(mainly) Windows, and run Java web services on Unix.

What do people do on i boxes?

As I wrote - same as for other platforms.

Phones, file shares and web services are a rather small
part of Java (phone are growing though).

The majority of Java work is business apps (some UI - often
web based, some business logic, some persistence in database
etc.).

Then I do hope you will drop this particular part of the argument now.

Sure.

Arne

 

[Arne Vajhøj]

But it's entirely in-band structure. Line breaks are a natural part of
texts.


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.

Arne

 

[Daniel Pitts]

That's a form of seeking backwards.

I suppose you're right, and my idea was basically a buffered backwards
seek.

 

[Lew]

I suppose you're right, and my idea was basically a buffered backwards seek.

Don't get me wrong - your idea is quite good.

 

[Jerry Gerrone]

If so, then that editor is broken. And if you edit it on a working editor
(say, by mounting the file system over the network and using vi on it
from the comfort of your nice, sane Unix work station)

There is nothing sane about a Unix workstation running vi.

 

[Tom Anderson]

Not at all.

Because market share is counted in dollars.

It bloody well is not!

Or are you saying that non-commercial distributions of Linux have zero
market share *by definition*?

tom

 

[Arne Vajhøj]

It bloody well is not!

Or are you saying that non-commercial distributions of Linux have zero
market share *by definition*?

No.

The HW is not free.

When you talk about server market share it is the cost of the HW
and the OS.

For good reasons - in the case of proprietary OS then the division
of cost between HW and OS are arbitrary.

The OS for a free OS (like Debian or FreeBSD) does not contribute
in itself.

It is a bit unfair, but it is very difficult to assign an
amount other than the one actually paid.

And the unfairness of counting 10 M$ systems equivalent to
1 K$ systems are a bigger problem.

Arne

 

[Tom Anderson]

In this forum people all the time try to make the claim that an OP meant
something not in the original post. For example, the other thread where
the OP asked how to produce a 'List <String1>' and everyone (except me)
assumed and argued that they *must* have meant 'List <String>', even
though they took great pains not to say so.

Did we ever get an indication from that guy whether he did or did not mean
String? I still assume that he *did* mean String, and that quite contrary
to taking great pains in his saying, he'd expressed himself poorly.

It's virtually a default presumption for me that new posters with
questions mean something other than or more than what they say. People
come here with problems they can't solve themselves, and we get two kinds
of them (caricaturing somewhat): dumb people with easy problems, and smart
people with difficult problems; it is not reasonable to assume that the
former have expressed themselves completely and correctly, and sadly, they
outnumber the latter.

So I would expand your advice to add that one eschew assuming anything
outside the problem statement.

I hope you don't mind if i decide not to travel with your Logical
Positivism Bus Company here; i would suggest that while we must not assume
anything outside the problem statement, we can suggest and hypothesise it.

Beyond that, because this is a discussion forum and not a help desk, it
is entirely appropriate to discuss the general applicability of
principles elicited from a specific problem. Thus, even if the OP did
want to speak only of log files, it is important and highly relevant to
point out that "text files" (about which they actually did ask) have a
wider and fuzzer meaning that certain ignorant trolls would believe.

Well, if not to point it out, to discuss the idea, at least .

tom

 

[Arne Vajhøj]

It is pretty much meaningless unless you're referring to the way a
programs handles data. Consider a file containing nothing but printable
characters:

- if a C or Java program reads the file byte by byte or parses it
by reading words separated by whitespace then line delimiters are
utterly meaningless and the program doesn't care whether the file
contains records or not.

- OTOH if a different program reads the same file a line at a time, e.g
C using fgets(), Java using BufferedReader.readLine(), then this is
pure record-level access.

But the text file itself is not "record-based". You can implement a
record-based format *on top of text* -- CSV goes further that way -- but
the resulting file, crucially, can still be manipulated with tools
designed for generic operations on arbitrary text files properly. In
particular, this should be lossless on it:

import java.io.*;

public class TextFileCopier {
public static void main (String[] args) throws IOException {
if (args.length< 3) {
System.out.println("Please specify source and" +
"destination file.");
return;
}
File f = new File(args[1]);
InputStream is = new FileInputStream(f);
Reader rdr = new InputStreamReader(is);
File g = new File(args[2]);
OutputStream os = new FileOutputStream(g);
Writer wtr = new OutputStreamWriter(os);
int c;
while ((c = rdr.read()) != -1) wtr.write(c);
}
}

But this won't be lossless on the strange file formats Arne has become
obsessed with. At the reading stage, the record boundaries in those file
formats will be translated into some newline character or another, likely
\u000A. When that happens, the distinction between those and literal
\u000A characters in the source file will be lost and can never be
regained.

Surely you agree that a file format cannot be regarded as a true text
file format unless the above TextFileCopier can copy all files in that
format faithfully?

Actually I think it is a bit weird to test if a file consists
of text lines without the program being line aware.

And the code is rather bad:
- you are not using args[0] (in Java args[0] does not contain the
name of the program)
- you are not calling close on rdr and wtr
but those are easy to fix.

And I am happy to inform you that the above program
actually works with VMS variable length files.

Dump of input:

Record type: Variable
File organization: Sequential
Record attributes: Implied carriage control
End of file block: 1
End of file byte: 16

007A6162 00030072 61620A6F 6F660007 ..foo.bar...baz. 000000

Dump of output:

VAX-11 RMS attributes
Record type: Variable
File organization: Sequential
Record attributes: Implied carriage control
End of file block: 1
End of file byte: 16

007A6162 00030072 61620A6F 6F660007 ..foo.bar...baz. 000000

So QED.

Arne

PS: for those with a VMS system that want to test themselves,
then remember to set the logical that tells Java to use
variable length files in stream mode.

PPS: I am actually somewhat surprised that it works. It is
not that easy to get something as stream oriented as this
to work in a record world. HP's Java and C engineers
must have been rather smart.

 

[Tom Anderson]

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

 

[Arne Vajhøj]

So which is it -- a tar-like archive of multiple text files, each with
internal newlines, or a single text file with a funny representation of
newlines? Arne indicated the latter while you seem to be indicating the
former.

Of course, neither are true text files -- both fail the TextFileCopier
test, in particular, and yours doesn't even pass the most elementary
sniff test -- calling that a text file would be like expecting

If the files can be read and written as text files by the shell,
Fortran, Cobol, C, C++, Java etc. then they seems to be text
by those that created those languages.

i and OpenVMS are quite different, so no surprise that Martins
description of i and mine of OpenVMS differs somewhat.

And your copier program actually works on OpenVMS, so ...

They belong to the Unicode (and indeed even the base ASCII) character
set, so by definition they *can* be included in text files.

Your weird definition.

The rest of us expect text files to contain printable
characters, which NUL is not.

Arne

 

[Arne Vajhøj]

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.

Now, who can point me at this atypical novel with count prefixes?

Docs or system or ... ?

Arne

 

[Arne Vajhøj]

Don't get me wrong - your idea is quite good.

For any serious (volume) usage it would be one of the first things
to get right.

Arne

 

[Arne Vajhøj]

No. Those editors, at minimum, will strip some information from the file,
even if you just open it and then save out a copy. If the original had my
hypothetical hidden message "the attack begins at midnight" encoded in a
pattern of actual 0x0A characters and record boundaries, the output will
not, and will generally have converted all 0x0A characters in the
original into record boundaries specifically, in that

foo<0x0A>bar<boundary>baz

would probably have ended up in the vi buffer (or emacs buffer, or
whatever) as

foo<0x0A>bar<0x0A>baz

Which is where you logic goes wrong.

You assume that the editor will store the data in a single
string separated by \n.

Not only does it not have to be done that way.

It would most likely not be done that way.

It is a horrible inefficient way to work with text.

and then output would be converted to

foo<boundary>bar<boundary>baz.

If a text editor like vi cannot losslessly load and re-save the file then
it is not a text file by any sane definition, including particularly
Arved's pretty darn good definition.

Not only is your logic flawed as described above.

But is very easy to open such a file in one of the text editors
that comes with the system and save it and verify that the file
did not change.

Arne