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) ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
