From roebuck at mdanderson.org  Wed Nov 16 20:52:00 2005
From: roebuck at mdanderson.org (Paul Roebuck)
Date: Wed, 16 Nov 2005 13:52:00 -0600 (CST)
Subject: [Rd] two-way communication using Unix pipes
In-Reply-To: <f68da330511160715m6ad1ab40s6744c67aed1998ff@mail.gmail.com>
References: <f68da330511160715m6ad1ab40s6744c67aed1998ff@mail.gmail.com>
Message-ID: <Pine.OSF.4.58.0511161341030.174462@wotan.mdacc.tmc.edu>

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)



[Rd] two-way communication using Unix pipes
Paul Roebuck