Hello, I am trying to communicate with R from a perl program. Because this code must be deployed on systems that are outside of my control I do not wish to pursue the RSperl.pm approach which requires that R be compiled to use shared libraries. I have a custom, light weight module I have used with other command line driven programs like Ferret and Grads. This module follows the standard perl procedures for forking a process, opening pipes and then redirecting STDOUT, STDIN and STDERR. Commands are sent out to the external program and my perl module then uses perl's select(2) function to listen for output from the program. Unfortunately, it doesn't ever seem to get a response from R on the redirected STDOUT or STDERR. Looking at the perl IPC::Run module I see that some programs are aware of whether they are talking to a tty or not and revert to 'batch behavior' if they don't detect a tty. Can someone please explain to me exactly what R is doing with the the standard IO handles and whether or not there is any simple way to convince it to behave as if it were talking to a user at the other end of a keyboard and terminal? I've already tried '--no-readline' but that doesn't solve my problem. Many thanks in advance for any suggestions. -- Jonathan Callahan [[alternative HTML version deleted]]
Jonathan Callahan wrote:> Can someone please explain to me exactly what R is doing with the the > standard IO handles and whether or not there is any simple way to convince > it to behave as if it were talking to a user at the other end of a keyboard > and terminal? I've already tried '--no-readline' but that doesn't solve my > problem. >This little noddy example works for me: #!/usr/bin/perl use FileHandle; use IPC::Open2; $pid=open2(*Reader, *Writer, "R --no-save"); print Writer "x=runif(10);print(mean(x))\n"; while($got=<Reader>){ print "Got ".$got; } Of course, without the \n in the command string it doesnt work at all, but I dont see any problems with R reading from stdin and writing to stdout.... This is on a Linux box, I dont think you mentioned an OS or platform... Baz
On Wed, 16 Nov 2005, Jonathan Callahan wrote:> I am trying to communicate with R from a perl program. Because this code > must be deployed on systems that are outside of my control I do not wish to > pursue the RSperl.pm approach which requires that R be compiled to use > shared libraries. > > I have a custom, light weight module I have used with other command line > driven programs like Ferret and Grads. This module follows the standard perl > procedures for forking a process, opening pipes and then redirecting STDOUT, > STDIN and STDERR. Commands are sent out to the external program and my perl > module then uses perl's select(2) function to listen for output from the > program. > > Unfortunately, it doesn't ever seem to get a response from R on the > redirected STDOUT or STDERR. > > Looking at the perl IPC::Run module I see that some programs are aware of > whether they are talking to a tty or not and revert to 'batch behavior' if > they don't detect a tty. > > Can someone please explain to me exactly what R is doing with the the > standard IO handles and whether or not there is any simple way to convince > it to behave as if it were talking to a user at the other end of a keyboard > and terminal? I've already tried '--no-readline' but that doesn't solve my > problem.You can always run a pseudoterminal (pty) between them which will solve your problem. You can get a copy of the source for a simple one from Steven's APUE. May have to modify the getopt() processing a bit on Linux. ---------------------------------------------------------- SIGSIG -- signature too long (core dumped)