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
--interactive and -f/-e
3 messages · Mick Jordan, Martin Maechler
Mick Jordan <mick.jordan at oracle.com>
on Tue, 28 Apr 2015 18:11:54 -0700 writes:
> 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:
Mick Jordan <mick.jordan at oracle.com>
on Tue, 28 Apr 2015 18:11:54 -0700 writes:
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
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