Re: [Rd] directing print.packageInfo to a file

From: Gabor Grothendieck <>
Date: Tue 03 Aug 2004 - 00:07:22 EST

From: Kurt Hornik <>

>>>>> Gabor Grothendieck writes:

> I already suggested using the pager as a workaround
> in the original thread although your pager workaround
> has the advantage of being 100% in R while mine used
> a batch file which defined a new pager.
> Note that R already supports
> options(pager = "console")
> but if you do this then it seems that capture.output
> still won't capture it. Thus one alternative solution
> would be to get capture.output to work with
> pager = "console" and modify print.packageInfo to
> take a pager= argument which it would pass down to
> ( already has a pager argument.)
> Then one could write:
> capture.output( print.packageInfo(help(package = chron),
> pager = "console"), file = "myfile.txt")
> That gets it down to one line although it still seems
> unnecessarily indirect when one could just write:
> print.packageInfo(help(package = chron), file = "myfile.txt")
> if print.packageInfo just had a file= argument.
> Furthermore, print.packageInfo ALREADY creates the file as a
> temporary file to hand over to so its not much of
> a stretch to give the user access to what it is already
> creating anyway.

The point about the proferred solution is that it works generally when is is desired to capture output that is "printed" via If we start adding extra arguments to print.packageIQR (which is documented to be internal, btw), we would need to do the same for print.libraryIQR and print.hsearch and ..., i.e. for all print() methods which in fact display something using as a "side effect". That seems suboptimal to me, when one can wrap the above in a very simple and generally applicable function (and just calling the print() generic rather than some method, btw).


That's a good point but if a command _already_ produces a file 
I think its logical that access to that file be given directly, 
even if that means having to add a file= argument in many commands.   
In my opinion, both our pager workarounds are too complex/geeky 
for a simple task.

I think this whole thing could be streamlined by extending the
pager= option to accept a connection, e.g.

           options(pager = file("a.txt"))

and then modifying the args of to:

function (..., header = rep("", nfiles), title = "R Information", 
  delete.file = FALSE, file, 
  pager = if (missing(file)) getOption("pager")) else base:file(file))

Now passing down the ... arguments from print.packageInfo
to only involves a one line change, namely, just
add three dots at the end of the call to within
print.packageInfo:, delete.file = TRUE, title = 
        paste("Documentation for package", sQuote(x$name)), ...)

and this automatically gives pager= and file= support to it.
(Note that currently the three dots are already in the arg list to print.packageInfo but are not used anywhere in the body of that
function.)  Modifying the other functions might be just as easy.

Also, while we are at it we could add pager= arguments
to sink and to capture.output.  With the above any of the following
would work:

   print.packageInfo(help(package = chron), file = "a.txt")

   print.packageInfo(help(package = chron), pager = file("a.txt"))

   capture.output(help(package = chron), pager = file("a.txt"))

   sink(pager = file("a.txt"))
   help(package = chron)

   oop <- options(pager = file("a.txt"))
   help(package = chron))

______________________________________________ mailing list
Received on Tue Aug 03 00:10:10 2004

This archive was generated by hypermail 2.1.8 : Wed 03 Nov 2004 - 22:45:04 EST