peculiar failure in bash

[abelew]

I cannot seem to figure out why, but if I use runr with bash and invoke an environment module in my shell, then the next bash block will not be able to connect to the socket created by runr.

I am looking into it, but I figure someone smrtr than me might see the answer.

Here are some arbitrary blocks which will cause runr to fail when render-ing/knitr-ing (at least on my systems):

Setup

library(knitr)
library(runr)
port <- sample(x=1000, size=1) + 10000
b <- proc_bash(port)
b$start()
knit_engines$set(bash=function(options) {
  knitr:::wrap(b$exec(options$code), options)
})
Sys.sleep(3)

Fine

echo "Hello, at this point everything is ok."

Still fine

module add gcc
echo "Still ok."

So sad

ls
echo "Do we get here (we do not I already know.)?"

Thank you very much for your time,
atb

Minor update in May 2018

I remembered and poked at this a little last night and found two potentially useful diagnosis points:

1. If I add a 1 second sleep between bash blocks, the failure occurs less often. I am guessing there might be some odd form of race condition therefore in the creating/reading of the /dev/tcp/port socket?
2. If I have a long line of text in my bash STDOUT, the readLines() in bash.R throws a warning() and all following requests fail. I did some searching for ways to increase the length of line read by readLines() but to no avail, I am betting there are smarter ways to handle that, perhaps by splitting long strings?