From vividsnow@gmail.com

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.

From vividsnow@gmail.com

multi-eof.pl

From vividsnow@gmail.com

loop {
  if $*IN.eof {
  say 'try reopen';
  $*IN = open($*IN.path, :r);
  }
  my $s = $*IN.Supply;
  react {
  whenever $s -> $buf {
  print $buf;
  LAST {
  say 'got eof';
  }
  }
  }
}

From vividsnow@gmail.com

loop {
  for $*IN.lines -> $line { say $line };
  say 'got eof' if $*IN.eof;
}

From toapole@gmail.com

still an issue on "Rakudo version 2017.02-109-g75e070fde built on MoarVM version 2017.02-7-g3d859008"

From @zoffixznet

On Sun, 13 Nov 2016 08​:07​:34 -0800, vividsnow@​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](rakudo/rakudo@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 rakudo/rakudo#1424

The RT System itself - Status changed from 'new' to 'open'

@zoffixznet - Status changed from 'open' to 'resolved'