[Rd] Wishlist: 'quietly' argument for .onAttach() / .First.lib()

Peter Ruckdeschel Peter.Ruckdeschel at uni-bayreuth.de
Wed Apr 19 00:59:39 CEST 2006

Summing up the discussions in this thread, I have built a package
'startupmsg' available (in a first version) for the moment at


(see documentation within)

In particular, I took up suggestions from Seth Falcon's mail as to the
condition system
in R as well as a  suggestion by Brian Ripley in some earlier reply in
this thread
to use options() to control start-up messages.

Any comments/suggestions are welcome.

If you find 'startupmsg' useful, you might decide to integrate (parts
of) it to the
'utils' package  (or some yet to be built package "packageutils" ) later
on ---
for the moment, I would simply submit it to CRAN in the next days.


Seth Falcon <sfalcon at fhcrc.org> writes:
>Paul Roebuck <roebuck at mdanderson.org> writes:
>>Prof Brian Ripley <ripley at stats.ox.ac.uk> writes:
>>> Similarly for Bill Dunlap's proposal: suppressMessages would squelch all
>>> messages from the call, not just the one from your package's startup
>>> Now, at present there may not be any, but that could well change as
>>> message() gets more widely used.
>> I found Bill's suggestion a bit scary myself; suppressing messages
>> when dealing with loading packages seems a bit like disabling the
>> compiler's warning messages - a bad idea. But it was a novel
>> approach.
>What's the use case where this would be scary?  suppressMessages
>doesn't supress warnings or errors, just messages.  If the info to be
>communicated to the user is important enough that it would be "scary"
>to not see it, then shouldn't it sent as a a warning or an error?
>> Given what you said above, do you favor the suggestion to use
>> message() instead of cat() for the purpose of .onAttach() startup
>> messages? I've seen message() before in the manpages but never saw
>> any documentation on how or when it might be considered appropriate
>> to use.


>>>>>> On Thu, 13 Apr 2006, Prof Brian Ripley wrote:
>>>>>>> I did think you could make use of an option to decide whether to
>>>>>>> the print the message or not, [snip]


>> Why would one want to represent a simple non-error message as a
>> condition in the first place?
>Because it allows another developer to have control over those
>messages.  That's the beauty of the condition system in R.  
>Right now, developers can choose to allow or suppress messages sent
>via message().  With a small change, developers could have a lot more
>control.  The message code could define a restart that would allow a
>developer-specified function to handle the message.  This could be
>useful, for example, to log all messages to a file.


>For anyone still with me:
>* If there was much concern about squelching "important" messages by
>  accident, then one could define a new subclass of simpleMessage, say
>  startupMessage or blatherMessage, and then suppress just those.
>* This use case of handling messages could also be addressed with a
>  logging system like Python's logging module.  Basically, it would
>  allow users to install log handlers, set priorities, etc.

More information about the R-devel mailing list