FileRead - Read data WITHOUT caring about <CRLF>

[Sheik]

Hi all,

I have a question/comment about FileRead.

I have a file of data that is NOT binary data, but I do NOT want to parse it on a line by line basis either, but instead grab chunks of the file at various offsets as needed.

The problem is that FileRead will read up to a CRLF, and then return with that set of data regardless of the value of [maxlen] that I provide to the FileRead command.

What I am looking for is for FileRead to have an option to simply ignore CRLF, and just return up to [maxlen] data that I provide to the command, OR, if the file is at EOF, return whatever data there is up until EOF.

So what I have done as a patch, is change FileRead to allow for negative values in [maxlen].
If a negative value is passed in, we mark a flag to tell it to NOT quit reading after finding a CRLF, but instead to keep going until maxlen is reached, or we run into the end of the file.

This patch works well, and I would like to submit it, to hopefully be taken.

However, I am thinking instead of overriding the functionality of FileRead, maybe I should make a new command?

Thoughts? Suggestions?

Scott

[Afrow UK]

You can use FileReadByte in a loop and concatenate to a buffer using StrCpy.

Stu

[Sheik]

Yeah, I thought of that, but there are 2 problems with doing it that way...

1) The FileReadByte translates the byte read into an integer.
> The byte is stored in the output as an integer (0-255).

2) I need to read very relatively large data files. Probably 10 M's or larger.
Calling that function, and reading each BYTE by BYTE is going to be horribly inefficient, and converting each integer read back into a string is even more horribly inefficient.


I had thought of making a new command called FileReadBytes that would take an optional [maxsize] parameter, but since FileReadByte does the BYTE -> int transalation, it seems like I should stay away from that name, since my new function would NOT translate the data read.

[Afrow UK]

As long as you don't keep calling the function in a section (thus moving the progress bar) then it shouldn't be that slow. To prevent that, call your function from within a function which itself is called from within a section.
You can use IntFmt $out %c $in to convert the ASCII value to a character. Don't forget you are only limited to 1023 characters in NSIS (or 8191 if using the special build).

Stu