Thanks for the clear explanation. At first glance seeking to the
current position seemed like it would be a no-op, but obviously things
are more complicated under the hood.
On Thu, Apr 26, 2018 at 11:35 AM, Gábor Csárdi wrote:
> I suspect the reason for the seek is this:
>
> cat("1\n", file = "fo
I suspect the reason for the seek is this:
cat("1\n", file = "foobar")
f <- file("foobar", blocking = FALSE, open = "r")
readLines(f)
#> [1] "1"
cat("2\n", file = "foobar", append = TRUE)
readLines(f)
#> [1] "2"
cat("3\n", file = "foobar", append = TRUE)
readLines(f)
#> [1] "3"
I.e. R can emul
The issue is that readLines() tries to seek (for reasons I don't
understand) in the non-blocking case, but silently fails for "stdin"
since it's a stream. This confused the buffering logic. The fix is to
mark "stdin" as unable to seek, but I do wonder why readLines() is
seeking in the first place.
Probably related to the switch to buffered connections. I will look
into this soon.
On Wed, Apr 25, 2018 at 2:34 PM, Randy Lai wrote:
> It seems that the behavior of readLines() in R 3.5 has changed for
> non-blocking pipeline.
>
>
> Consider the following R script, which reads from STDIN line b
It seems that the behavior of readLines() in R 3.5 has changed for non-blocking
pipeline.
Consider the following R script, which reads from STDIN line by line.
```
con <- file("stdin")
open(con, blocking = FALSE)
while (TRUE) {
txt <- readLines(con, 1)
if (length(txt) > 0) {
cat
