On 01/04/2010 09:39 PM, Iñáki Baz Castillo wrote:
> Hi, by redirecting $stderr to a logger (Logger or SyslogLogger instance) I've 
> realized that Kernel#warn prints an extra \n so the logger is called twice 
> (the second one with an empty line).
> 
> The "warn" code shows it clearly:
> 
>   static VALUE
>   rb_warn_m(self, mesg)
>       VALUE self, mesg;
>   {
>       if (!NIL_P(ruby_verbose)) {
>           rb_io_write(rb_stderr, mesg);
>           rb_io_write(rb_stderr, rb_default_rs);
>       }
>       return Qnil;
>   }
> 
> 
> So for example by redirecting $stderr to a Logger instance
> 
>   warn "hello"
> 
> I get:
> 
>   # Logfile created on 2010-01-04 21:32:21 +0100 by logger.rb/20321
>   F, [2010-01-04T21:32:38.981099 #22370] FATAL -- : hello
>   F, [2010-01-04T21:32:38.981385 #22370] FATAL -- :
> 
> 
> Can this be avoided (without rewritting "warn" call)? Thanks.

Frankly, I believe redirecting stderr to a logger instance is a broken 
approach.  Why?  A logger has a completely different interface, i.e. it 
accepts at least a log level and the message to log.  Based on that it 
decides whether to output the message and how to format it.  A stream 
like stderr readily accepts anything send to it and it will output it 
(if there are no errors of course).  There is no formatting or deciding 
going on.

I do not know your use case or what you want to achieve with this but it eems redirecting a stream of bytes to a logger is not a good idea on 
the design level already.

Kind regards

	robert



-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/