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

From: Peter Ruckdeschel <>
Date: Tue 18 Apr 2006 - 22:59:39 GMT

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 <> writes:
>Paul Roebuck <roebuck at> writes:
>>Prof Brian Ripley <> 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. mailing list Received on Wed Apr 19 09:04:03 2006

This archive was generated by hypermail 2.1.8 : Wed 19 Apr 2006 - 04:17:45 GMT