[Rd] stdout == 'Terminal' or 'File' {was 'bad interaction ...'}

[Martin Maechler]

>>>>> "BDR" == Prof Brian Ripley <ripley at stats.ox.ac.uk>
>>>>>     on Wed, 12 May 2004 09:04:05 +0100 (BST) writes:

    BDR> First, on an R console, stdout() is normally neither a
    BDR> `normal file' nor a `user terminal'.  

strictly yes, but that was not the point.
I have been looking for an API we could use to find some useful
information, and the original topic was about Sweave where
there will a file {when in normal use}.

    BDR> Let alone under an embedded R ... or use under ESS (where for you,
    BDR> Martin, it is neither).

well, I knew this, but ESS (i.e. 'comint' in Emacs) is quite
good at behaving like a user terminal in many situations;
e.g the 'scp' (secure copy) "visual counter" works very nicely
in Emacs' *shell* buffers.

    BDR> On vanilla R under Unix-alikes (and Rterm but not
    BDR> otherwise) what stdout is is a function of the C
    BDR> runtime system.  It's up to the C system if it tells
    BDR> you what stdout has been redirected to, and if it can
    BDR> tell you whether it is a terminal, or a pty (as used
    BDR> under some versions of Emacs) or a file or a socket
    BDR> ....  The information is at best unreliable.

ok; that (the unreliabilty of the info you get) is bad news.
Thank you for the clarification.

    BDR> interactive() is as good a test as we have, and I think
    BDR> if a better test is required in the interactive case,
    BDR> the user should be asked.

we can live with that, but I think other softwares at least try
to do better here.

------------------

A completely different way, less nice in several ways, but maybe
more reliable:  There's a workaround we could start using here:
ESS has been setting
     options(STERM= ...)
for a while now to indicate to the S process which kind of
"terminal" (excuse the term) it is running in.

The ESS manual currently contains

>> Is the Statistical Process running under ESS?
>> =============================================
>> 
>>    For the S languages (S, S-Plus, R) ESS sets an option in the current
>> process that programs in the language can check to determine the
>> environment in which they are currently running.
>> 
>>    ESS sets `options(STERM="iESS")' for S language processes running in
>> an inferior `iESS[S]' or `iESS[R]' buffer.
>> 
>>    ESS sets `options(STERM="ddeESS")' for independent S-Plus for Windows
>> processes running in the GUI and communicating with ESS via the DDE
>> (Microsoft Dynamic Data Exchange) protocol through a `ddeESS[S]' buffer.
>> 
>>    Other values of `options()$STERM' that we recommend are:
>> 
>>    * `length':     Fixed length xterm or telnet window.
>> 
>>    * `scrollable': Unlimited length xterm or telnet window.
>> 
>>    * `server':     S-Plus Stat Server.
>> 
>>    * `BATCH':      BATCH.
>> 
>>    * `Rgui':       R GUI.
>> 
>>    * `Commands':   S-Plus GUI without DDE interface to ESS.
>> 
>>    Additional values may be recommended in the future as new interaction
>> protocols are created.  Unlike the values `iESS' and `ddeESS', ESS
>> can't set these other values since the S language program is not under
>> the control of ESS.

and maybe we (R developers) should also consider setting some of
these (e.g. STERM = "Rgui" in that case) -- at least when the
info is available (and somewhat reliable) and even better think
about what else (better) could be done, working with  options()
settings as a workaround for this problem.

Also (for the original topic), maybe  Sweave() could set
options(STERM = 'Sweave') if options(STERM = 'BATCH) is not good
enough.  Then, code like Martin Schlather's use
      switch(getOption("STERM"), 
             "BATCH" =  { .........},
	     ....
	     )

    BDR> On Wed, 12 May 2004, Martin Maechler wrote:

    >> >>>>> "MartinS" == Martin Schlather <schlather at cu.lu>
    >> >>>>> on Wed, 12 May 2004 09:15:17 +0100 writes:
    >> 
    MartinS> Dear Ben,
    >>
    MartinS> I do not know how to solve the general problem that
    MartinS> backspaces cause within Sweave, but which are
    MartinS> needed to implement running counters.
    >>  aha!  now I understand more what you are talking about.
    >> 
    >> This is a more interesting problem, in general: It's not
    >> quite a matter of if(interactive()) that Ben tried, but
    >> really you want to find out if the stdout() connection
    >> you are using is a normal file (where you don't need or
    >> want a running counter) or a user terminal where Martin
    >> Schlather applied the 1^H2^H... ('1' Backspace '2'
    >> Backspace ..) trick.
    >> 
    >> Any ideas what can be done here, using our current
    >> connection tools -- or is there the need for something
    >> new?  Interesting topic!
    >> 
    >> Martin Mächler
    >> 
    >> PS. I know that strictly speaking the subject question is
    >> non-sense, since, at least on Unix-alikes, a console is a
    >> special file as well, and stdout is always a file.

    BDR> -- Brian D. Ripley, ripley at stats.ox.ac.uk Professor of
    BDR> Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
    BDR> University of Oxford, Tel: +44 1865 272861 (self) 1
    BDR> South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG,
    BDR> UK Fax: +44 1865 272595