AutoHotkey-Util icon indicating copy to clipboard operation
AutoHotkey-Util copied to clipboard

Subprocess.ahk's StreamReader needs AtEndOfStream

Open mfaizsyahmi opened this issue 3 years ago • 2 comments

In WScript.Shell.Exec, some streams need some time to finish reading, so we poll AtEndOfStream and collate the ReadAll

In Subprocess.ahk's case it's the opposite. Doing a drop in replacement results in a script polling this nonexistent property (which returns a falsy value) and so it is stuck in a polling loop thinking EOF is far far away.

~~And yeah, I can write my code around it but it'd be a nice thing to have to facilitate a drop-in replacement.~~ edit: scratch that, this is an important property that should be exposed on the same level as the Read method.

mfaizsyahmi avatar Feb 06 '22 06:02 mfaizsyahmi

I have boiled down the error to the RawRead at StreamReader.ReadAll.

According to the docs:

If a Try statement is active and Bytes is non-zero but no bytes were read, an exception is thrown. AtEOF can be used to avoid this, if needed.

However, at File.AtEOF:

This property should be used only with an actual file. If the File object was created from a handle to a non-seeking device such as a console buffer or pipe, the returned value may not be meaningful, as such devices do not logically have an "end of file".

So when I have a try block somewhere higher in the stack to catch for other problems (e.g. program cannot open a file), the RawRead at StreamReader.ReadAll will throw an error.

Proposed solution

Wrap the while block in a try block. When the end of stream is reached, the exception thrown by RawRead will be ignored instead of travelling up the stack.

			try {
				while (read := this.Stream.RawRead(data, 4096))					
					NumPut(0, data, read, "UShort"), all .= StrGet(&data, read, encoding)
			}

Of course, StreamReader should also have a AtEndOfStream property that returns the stream's file object's AtEOF.

		AtEndOfStream[] {
			get {
				return this.Stream.AtEOF
			}
		}

mfaizsyahmi avatar Feb 06 '22 10:02 mfaizsyahmi

This repo's maintainer has not been active for 4+ years, so I doubt he would respond to this. Would love to see a proper fork with these changes though, AutoHotKey sorely needs a proper and well-maintained Subprocess library.

archiif avatar Feb 07 '22 20:02 archiif