On Sun, 13 Nov 2016 08:07:34 -0800, vivids...@gmail.com wrote: > Hello > > It is expected to be able to pass multiple eof-s (by pressing Ctrl+D). > > working p5 script: multiple-eof.pl > and two variants of p6 scripts, which falls to endless loop after > first "eof". > > Rakudo version 2016.10 built on MoarVM version 2016.10 implementing > Perl 6.c.
Thanks for the report. Ironically, what you describe is the current behaviour I see with $*IN.lines (but not .Supply), however *that* is the bug, not the endless loop. I'm guessing Perl 5's readline simply behaves like C's read() does, hence why you can spam it with EOFs and still get it to try to read more. In our handles, however, we know when we've already reached EOF even for non-seekable handles. I rather we don't special case [some] IO::Handle read methods to ignore EOF for TTYs, so I unified[^1](https://github.com/rakudo/rakudo/commit/359efef709) IO::Handle.get (and by extension IO::Handle.lines) to behave the same as .read and related methods and not attempt to read if we've reached EOF. (I wrote the tests to cover that, but even with our convoluted `run-with-tty` test routine they did not cover the bug, so I just left it without tests). As far as replicating Perl 5's behaviour, I can imagine situtations where that'd be handy and it would be nice to have a non-NQP way to achieve it. I think nqp::getstdin() (and *out/*err) should reset the handles. So they'd flush buffers, if any, set byte_position and eof_reported to zero. This way, the end user could just do `$*IN.=open` if they require to "reset" the $*IN and attempt to read from STDIN again. I filed that as https://github.com/rakudo/rakudo/issues/1424
