file_read_line

read_file is what I am using now, but file_read_line is a function in almost every language, and normally reads through the entire file before resetting the file seek pointer once EOF is found.

As I understood the help file, its supposed to read the file until encountering a CR, and then put the line in the buffer, moving the file seek pointer to the next character in the file in preparation for the next call of file_read_line. But it appears that if you have a newline on its own, its incorrectly interpreted as EOF. So doing a file_read_line on a file with a few blank lines scattered throughout never makes it through the whole file. As soon as a blank line is encountered, further calls to file_read_line returns 0 or no bytes read. So file_read_line can't be used on a file with a blank line in it? That's a fairly useless function, since most text files have a blank line or two. Some even start with one, in which case this function doesn't work at all.

In order to read past a blank line the file must be reopened, file pointer moved to where it left off, and continue. So unless your file has no blank lines, this function is basically useless. I seem to recall using it before and not seeing this behavior so I thought perhaps it changed over time. Currently running FW 1.5.78.

My file contains this:

---

11:32:07 > Discovery profile: Default discovery profile
11:32:07 > Discovery class: data-link (data-link layer)
11:32:07 > Discovery on: 192.168.1.0/24
11:32:07 > Discovery round starting.

11:32:08 > Discovery progress 25%

---

button_event[vdvTest, 1]
{
    push:

        local_var sString[512]
        stack_var slong slFH, slBytesRead

        slFH  = file_open('test.txt', file_read_only)
        slBytesRead = file_read_line(slFH, sString, 512)
        while(slBytesRead)
            slBytesRead = file_read_line(slFH, sString, 512)
        db("'slBytesRead: ', itoa(slBytesRead)")
        dbug("'Line read: ', sString")
        file_close(slFH)    }
}

This is the ouput:
(13:09:59):: File open result: 2
(13:09:59):: slBytesRead: 55
(13:09:59):: Line read: 11:32:07 > Discovery profile: Default discovery profile
(13:09:59):: slBytesRead: 57
(13:09:59):: Line read: 11:32:07 > Discovery class: data-link (data-link layer)
(13:09:59):: slBytesRead: 45
(13:09:59):: Line read: 11:32:07 > Discovery on: 192.168.1.0/24
(13:09:59):: slBytesRead: 36
(13:09:59):: Line read: 11:32:07 > Discovery round starting.
(13:09:59):: slBytesRead: 0
(13:09:59):: Line read:
(13:09:59):: Line read:

The line after the CRLF on its own, "11:32:08 > Discovery progress 25%" is never read.


If I insert a newline as the first line, I don't get anything in the buffer.
Paul

That's out of the help file example, and the only difference is seeding the result to get into the while loop. Does your code work after a line with CRLF appears on its own? In other words, two CRLFs in a row?
Paul

KielL wrote: »

This seemed like very strange behavior, so I checked the definition in NetLinx help. FILE_READ_LINE returns >= 0 on success, and a few negative values for failure (-9 for when EOF is reached). So your WHILE loop should be:

while(slBytesRead >= 0)
{
// stuff
}

I don't have an NX processor to test with, but with my NI, blank lines with only a CRLF return 0 and I can read several in succession without FILE_READ_LINE saying I've hit EOF. I don't think I've ever noticed that it doesn't count CRLF's in the result. I must have lucked out and never had to loop over any blank lines.

That must be it. I guess what it does is it removes the crlf prior to returning the bytes read which is a little counterintuitive. Therefore, if that is the only thing on that line, it returns 0 as the bytes read, even though it obviously read them. I had thought that it would have returned a positive integer since it has to read the crlf, but I guess since its removed, its not counted as part of the bytes read. I'm still confused why it removes the crlf, since in my case I need them, and now have to add it back. Nonetheless, at least using file_read_line instead of file_read takes care of advancing the read pointer automatically which is what I wanted. I am now slurping the whole file using file_read, but that can be slow with big files so this is a better alternative for what I am doing.
Thanks for taking a second look!
Paul