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

Wed, May 12, 2004 4:23 AM

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

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@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@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

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

Thread (8 messages)