Skip to content

--interactive and -f/-e

3 messages · Mick Jordan, Martin Maechler

#
I was surprised by this:

R --interactive -e 'interactive()'

bash-3.2$ R -q -e 'interactive()' --interactive
 > interactive()
[1] FALSE
 >

as the command options document says that --interactive should force 
interactive=TRUE:

" When *R* is run in a terminal (via |Rterm.exe| on Windows), it assumes 
that it is interactive if ?stdin? is connected to a (pseudo-)terminal 
and not if ?stdin? is redirected to a file or pipe. Command-line options 
--interactive (Unix) and --ess (Windows, |Rterm.exe|) override the 
default assumption"

But the code in system.c does this:

R_Interactive = R_Interactive && (force_interactive || isatty(0));

R_Interactive is set to FALSE in the -e/-f processing, and 
force_interactive is set to TRUE in the --interactive processing, so 
there is no way that it can ever override -e/-f. It seems that 
--interactive can only have an effect for something like a pipe. Is this 
actually the expected behavior?

Mick Jordan
#
> I was surprised by this:
    > R --interactive -e 'interactive()'

    > bash-3.2$ R -q -e 'interactive()' --interactive
    >> interactive()
    > [1] FALSE
    >> 

    > as the command options document says that --interactive should force 
    > interactive=TRUE:

    > " When *R* is run in a terminal (via |Rterm.exe| on Windows), it assumes 
    > that it is interactive if ?stdin? is connected to a (pseudo-)terminal 
    > and not if ?stdin? is redirected to a file or pipe. Command-line options 
    > --interactive (Unix) and --ess (Windows, |Rterm.exe|) override the 
    > default assumption"

    > But the code in system.c does this:

    > R_Interactive = R_Interactive && (force_interactive || isatty(0));

    > R_Interactive is set to FALSE in the -e/-f processing, and 
    > force_interactive is set to TRUE in the --interactive processing, so 
    > there is no way that it can ever override -e/-f. It seems that 
    > --interactive can only have an effect for something like a pipe. Is this 
    > actually the expected behavior?

I did not write the code, but maybe "yes".

It may also seem a bit peculiar that it matters *where* on the
commandline --interactive is given :

	R -q -e 'interactive()' --interactive

behaves quite differently from	

	R --interactive -q -e 'interactive()'
and	R -q --interactive -e 'interactive()'

the latter two behaving equally, and indeed just starting R
interactively and not obeying the '-e ..' part(s)  at all.

Reading the source shows that -e is really just a short cut for
-f / --file=*, because -e writes to a tempfile and then proceeds
as -f (with the tempfile).

As you mentioned "something like a pipe": '--interactive' does
work fine when R is reading from stdin, not just via a pipe,

  $ echo 'interactive(); 1+1' | R --interactive --vanilla -q
  > interactive(); 1+1
  [1] TRUE
  [1] 2
  > 
  $ 

but of course, e.g., also by explicitly reading a file from stdin : 

  $ echo 'interactive(); commandArgs()' > /tmp/e1.R
  $ R --interactive --vanilla -q  < /tmp/e1.R
  > interactive(); commandArgs()
  [1] TRUE
  [1] "/........../bin/exec/R"
  [2] "--interactive"                                   
  [3] "--vanilla"                                       
  [4] "-q"                                              
  > 
  $ echo 'x <- 1:7; interactive(); x' > /tmp/e2.R
  $ R --interactive --vanilla -q  < /tmp/e2.R
  > x <- 1:7; interactive(); x
  [1] TRUE
  [1] 1 2 3 4 5 6 7
  > 
  $ 

So, in principle it should not seem hard to make --interactive
work for '-e' and '-f' as well, but I don't see quickly how.
Just changing the line in unix/system.c you've mentioned above
is clearly not enough.

Martin Maechler
ETH Zurich
1 day later
#
On 4/29/15 3:20 AM, Martin Maechler wrote:
Thanks for the detailed assessment. When implementing a feature (I'm on 
the FastR project) I usually go by what the manual says, then check it 
against GnuR, and then if they don't match, read the source code. I'd be 
just as happy for the manual to be fixed rather than the code.

Mick