[V2] FileObj.ReadLine() autotrims trailing LF/CRLF

[SKAN]

AFAIK, my RunCMD() is the only one which uses .ReadLine() with a pipe.
I understand omitting LF/CRLF is highly convenient when dealing with files.. but not with a pipe.
RunCMD() function relies on the fact that empty StdOut lines always contain a LF or a CRLF and will break-loop when StrLen(Line) is 0.

This behavior isn't available in V2 and I haven't been able to find a way to port it for past several months.
Suffixing a CRLF to .ReadLine() is error prone because some commands like ping outputs a single line in 2 passes and my function would insert an erroneous CRLF amidst a line.

If it isn't too late... and is feasible, I request you to please revert to V1 behavior, or provide an option to retain the trailing LF/CRLF.
If not, please confirm and I will fallback to Sean's original method of copying to buffer and processing it with DllCall()s.

Thank you.

[lexikos]

It is too late to change the behaviour for v2.0 (and I prefer the default to exclude line endings), but an option could be added. Any suggestions for syntax?

PeekNamedPipe can differentiate "no data will ever be available" (return value 0, such as when pipe is closed from the other end) from "no data currently available" (*lpTotalBytesAvail is non-zero). It can be used in conjunction with the File object. I think the key parts are:

Code: Select all

DllCall("SetNamedPipeHandleState", "ptr", readHandle, "uint*", PIPE_NOWAIT:=1, "ptr", 0, "ptr", 0)
...
while DllCall("PeekNamedPipe", "ptr", readHandle, "ptr", 0, "int", 0, "ptr", 0, "uint*", &bytes:=0, "ptr", 0) {
    ...
}

Currently I think AtEOF breaks pipes, because it uses SetFilePointerEx to determine the position of the file pointer. It could be improved to support pipes by checking GetFileType and/or GetNamedPipeInfo and then PeekNamedPipe. However, I'm not sure whether to consider "end of file" to be when there is no available data, or only when the pipe has closed. For a file, I think it is possible to reach end of file and then have more data appended by another process, effectively making AtEOF an indicator of available data.

However, it doesn't solve the problem of identifying whether a complete line (with ending) was read. I checked code that I'm using to read error output from an AutoHotkey process, but found that my code would just ignore empty lines, and would not differentiate between a partial line and a line with ending. (It's not an issue for my use case.)

One simple solution would be to add a property or output parameter for the last line ending encountered by ReadLine. A property would perhaps have similar use to AtEOF.

Other solutions would be to add new modes or methods for reading data, such as flags to control what happens if a line ending (or any data) isn't available, or a method which buffers data until a specific string is found. Currently the File object is designed with a fixed buffer size in mind, and it buffers raw bytes purely for performance, but the caller could provide a buffer or variable reference.

A simple solution which also has some use with file I/O would seem to be ideal, since dealing with pipes generally requires DllCall either way (although maybe that's not actually the case for "*" and "**", or "\\.\pipe\etc").

[SKAN]

Hi @lexikos

I am sorry for the late reply!

It is too late to change the behaviour for v2.0 (and I prefer the default to exclude line endings), but an option could be added. Any suggestions for syntax?

I am not good enough to suggest syntax.. Any option decided by you will be of a great benefit.
 

Here is a temp version for V2

Given AHK2 is now stable, you should post this up as an official, non-temp release in the v2 Scripts forum.

But the temp version has flaws.
FileObj.AtEOF/FileObj.Pos shouldn't be used. Also, FileObj.Pos returns negative positions.

[Adventurer]

Here is a temp version for V2

Given AHK2 is now stable, you should post this up as an official, non-temp release in the v2 Scripts forum.

But the temp version has flaws.
FileObj.AtEOF/FileObj.Pos shouldn't be used. Also, FileObj.Pos returns negative positions.

Thank you, though I'm a little confused as to why you're replying to me from this thread. Was it an accident or is this somehow related to what's being discussed here?