Repeatedly divide read buffer size by 8 until success. Fixes #11481.

[twadleigh]

This solution fixes julia --lisp on Windows 7 by repeatedly halving dividing by 8 the number of bytes requested on a failed read and trying again, implementing the suggestion of @vtjnash in #11481.

The behavior should be unchanged on Windows 10 (or other platforms for which there wasn't previously a failure).

[twadleigh]

Tests passed for me locally (64-bit Win7). Looks like the AppVeyor failure was due to some network issue on their end?

[tkelman]

LGTM. Possible to test? Maybe add a comment too?

[twadleigh]

I'll add a comment and a test.

[twadleigh]

I have been unable to construct an automated test case for this.

One issue is that I can't duplicate the error if julia is run in mintty, even if I run an inner instance of julia through cmd. For instance:

shell> cmd /c julia --lisp

results in a functional femtolisp, even for a julia without this patch, so the problem just doesn't exist if there is a mintty somewhere in the parentage. Since the testbed is almost certainly always going to be run from a cygwin/msys2 terminal, this looks like a deal killer.

Further, if input is piped in to femtolisp, it works OK, without the patch. For instance, I was considering doing something like

echo (exit 42) | julia --lisp

and testing the return code. If I got 42, then the lisp worked. If it wasn't able to process the input and returned immediately, I'd get some other return code (presumably). Unfortunately, this command actually works for the unpatched julia.

In sum, the bug only manifests if:

• cmd is the only shell in the process's parentage;
• input is requested interactively.

So automating a test case might require more cleverness than I can muster.

[tkelman]

fair enough. appveyor and most people who would run Base.runtests won't happen through mintty, so it's okay if some tests would need to be run outside of mintty to actually catch a problem.