Re: New to LUA, trying to read from a file

wow that was fast... let me see if I got all this correct.

First, as far as the format of the log file, I may have to look at it in a hex editor. I don't know the format they used while writing the file, I just know it is written as .log and it seems generally expected that word pad can view it just fine. So perhaps more on that to come, sounds like a place to start.

shouldn't it be "*a"? Check
http://www.lua.org/manual/5.1/manual.html#pdf-file:read ...
Also, you can try to print the length of the string with
print(#logstring).

Using *a produced the same results, I remember trying multiple ways due to my google searching. If one is correct and the other is not, that is one thing I was hoping to learn from this little experiment :)

I put the print statement in to see the length of the string. It returns 2345630, even though it only prints those first few characters. I found that interesting. Am i getting to large a size for a single string? I could process each line individually...

Couple of things:
1) How big is your log file? Are you trying to read too much? You may want to read line-by-line with "*line" instead of "*all", though it is more inefficient.
2) Here's a recent snippet I used:
local file = io.open(feed,"r")
while true do
local line = file:read("*l")

if line == nil then break end

text = line .. "\n" .. text
end

Well the log file is 2,291KB but I tried a very short one, of only about 4KB with the exact same results. I tried implementing this line by line code to see how it would turn out. If I print text outside the end statement, I get the exact same output as when I read everything at once. I then print the length of the string as suggested earlier and I end up with 4. I even tried adding a print of line inside the while loop just to see if I could simply print each line as it reads it. It prints the exact same text one time. It appears that reading a line at a time is stopping after the first attempt, which still has output I don't understand in it.

So I am probably back to, how is this file formatted exactly. I believe the logs were written with the idea of opening them in word pad for reading, but I will see about getting a hex editor and comparing this to a standard text file, which I have seen work.

On Tue, Oct 7, 2008 at 10:46 PM, James Dennett <james.dennett@gmail.com> wrote:

On Tue, Oct 7, 2008 at 7:26 PM, Brian Sanders <brian.sanders@gmail.com> wrote:

Hello, I am new to LUA and was trying to do some basic scripts to get a feel for it. I have tried to make a basic script to parse through a log file and display simple output. I have the following code which I thought I understood just fine.

print ("opening file for reading")
logfile = io.open("system.log","r")
logstring = logfile:read("*all")
print(logstring)

What is confusing me is, I can create a new text document, and just type a few words in it. Then I can use this script (unless in my many variations I posted the wrong one) and get the text back out. If I could get past this, I would then do some small matching off the log file. Unfortunately it only works when I make my text document. When I grab the actual log file I am trying to parse, it only returns a space, a square, and then the first character in the file. When opening this log file in word pad it does look normal with line returns after each log entry. In notepad however the line returns are shown as squares. I am therefore led to believe this must have something to do with formatting of this file, but I really don't know. Can anyone point me in the right direction here? I just don't see how these line returns could be the problem when it does not even parse that far, it just gets to the first character.

Thanks for helping a new guy out,
Brian

What's the format of the log file, exactly? In particular, what charset is it using (range and encoding), and what newline format? A hex dump of (the start of) the file can be very helpful in guessing that, if it's not documented somewhere. You mention "notepad", so I might guess that you're on Windows, which increases the probability that the file is some variant of UTF16, possibly UTF-16LE with a BOM (byte order mark). But that's a wild guess, and not likely to be right.

Unfortunately the simple term "text file" covers a whole family of formats.

-- James

--
"Faithless is he, who says 'farewell', when the path darkens
"you just keep on trying till you run out of cake"