R devel - Feb 2015 - Output to "raw console" rather than stdout/stderr?

In R, there's readline(), which is great because you can prompt the user,
e.g.

    ans <- readline("Would you like to install Pandoc? [y/N]: ")

without having to worry the message is intercepted by
capture.output(), sink() or similar (which is used by dynamic report
generators among other things).  The message will always reach the
user.  (You can use sink(..., type="output") and sink(...,
type="message") to confirm this.)

Does anyone know of a similar function that outputs the message to
"raw console" *without* pausing for user interrupt?  This far I came
up with:

cmsg <- function(...) {
  if (.Platform$OS.type == "windows") {
    pager <- "console"
  } else {
    pager <- "cat"
  }

  ## Write output to a temporary file
  fh <- tempfile()
  on.exit(file.remove(fh))
  cat(..., file=fh)

  ## Display file such that it cannot be captured/intercepted by R.
  file.show(fh, pager=pager)
}

but if a less ad hoc approach exists, I'd like to hear about it.

Thank you,

Henrik

Why do you need this? The sink system is often specifically needed to
capture such messages and display them to the user, for example in an
embedded environment. Many applications would not work when you bypass
the stdout/stderr set by the system. For example tools like knitr or
rapache need to capture stdout to get the output and insert it in a
report or webpage.

If you really want to, perhaps you could use something like
system("echo hello") to send a message to stdout via another process.


On Sun, Feb 1, 2015 at 11:13 AM, Henrik Bengtsson <hb at biostat.ucsf.edu>
wrote:
> In R, there's readline(), which is great because you can prompt the
user, e.g.
>
>     ans <- readline("Would you like to install Pandoc? [y/N]:
")
>
> without having to worry the message is intercepted by
> capture.output(), sink() or similar (which is used by dynamic report
> generators among other things).  The message will always reach the
> user.  (You can use sink(..., type="output") and sink(...,
> type="message") to confirm this.)
>
> Does anyone know of a similar function that outputs the message to
> "raw console" *without* pausing for user interrupt?  This far I
came
> up with:
>
> cmsg <- function(...) {
>   if (.Platform$OS.type == "windows") {
>     pager <- "console"
>   } else {
>     pager <- "cat"
>   }
>
>   ## Write output to a temporary file
>   fh <- tempfile()
>   on.exit(file.remove(fh))
>   cat(..., file=fh)
>
>   ## Display file such that it cannot be captured/intercepted by R.
>   file.show(fh, pager=pager)
> }
>
> but if a less ad hoc approach exists, I'd like to hear about it.
>
> Thank you,
>
> Henrik
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

On Sun, Feb 1, 2015 at 1:39 PM, Jeroen Ooms <jeroenooms at gmail.com>
wrote:
> Why do you need this? The sink system is often specifically needed to
> capture such messages and display them to the user, for example in an
> embedded environment. Many applications would not work when you bypass
> the stdout/stderr set by the system. For example tools like knitr or
> rapache need to capture stdout to get the output and insert it in a
> report or webpage.
It's mostly so I can send partial "prompt" messages to the user
and at
the very end use readline() to query for a decision.   The strategy of
outputting "now and then" is used by install.packages() et al., but
unfortunately it outputs to stdout, e.g.
> options(menu.graphics=FALSE)
> bfr <- capture.output(install.packages("R.methodsS3",
repos="@CRAN@"))
Installing package into 'C:/Users/hb/R/win-library/3.2'
(as 'lib' is unspecified)
Selection: 1
Selection: 1
Selection: 1
trying URL
'http://cran.rstudio.com/bin/windows/contrib/3.2/R.methodsS3_1.6.1.zi
p'
Content type 'application/zip' length 55873 bytes (54 KB)
opened URL
downloaded 54 KB
> str(bfr)
 chr [1:169] "--- Please select a CRAN mirror for use in this session
---" ...

Note how the user is prompted "Selection: " without any clue on what
to answer.  It would of course be better if those message would have
been sent to stderr, but you could imagine that also stderr is
captured by report generators.  In that case, these "prompt" message
would be hidden from the user.  These kind of "prompt" messages are of
no use to the final report and similar.

To summarize: I would like a third stream "prompt" dedicated for
message to the "interactive" user, in addition to the current
"output"
(stdout) and "message" (stderr) ones.  This "prompt" stream
would be
to the terminal what the GUI prompts/dialogs are in windowed
environments.   I think of this as readline() already sends to the
"prompt" stream (unless that is just an bug/undocumented features that
I'm misinterpret).
>
> If you really want to, perhaps you could use something like
> system("echo hello") to send a message to stdout via another
process.
Yes, that's the spirit of my cmsg() below.

Hope this makes more sense now

Henrik
>
>
> On Sun, Feb 1, 2015 at 11:13 AM, Henrik Bengtsson <hb at
biostat.ucsf.edu> wrote:
>> In R, there's readline(), which is great because you can prompt the
user, e.g.
>>
>>     ans <- readline("Would you like to install Pandoc? [y/N]:
")
>>
>> without having to worry the message is intercepted by
>> capture.output(), sink() or similar (which is used by dynamic report
>> generators among other things).  The message will always reach the
>> user.  (You can use sink(..., type="output") and sink(...,
>> type="message") to confirm this.)
>>
>> Does anyone know of a similar function that outputs the message to
>> "raw console" *without* pausing for user interrupt?  This far
I came
>> up with:
>>
>> cmsg <- function(...) {
>>   if (.Platform$OS.type == "windows") {
>>     pager <- "console"
>>   } else {
>>     pager <- "cat"
>>   }
>>
>>   ## Write output to a temporary file
>>   fh <- tempfile()
>>   on.exit(file.remove(fh))
>>   cat(..., file=fh)
>>
>>   ## Display file such that it cannot be captured/intercepted by R.
>>   file.show(fh, pager=pager)
>> }
>>
>> but if a less ad hoc approach exists, I'd like to hear about it.
>>
>> Thank you,
>>
>> Henrik
>>
>> ______________________________________________
>> R-devel at r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel