Why does "warn" print a extra \n?

Ruby
1

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.

2

On 01/04/2010 09:39 PM, Iñaki Baz C. wrote:

  if (!NIL_P(ruby_verbose)) {

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
seems redirecting a stream of bytes to a logger is not a good idea on
the design level already.

Kind regards

robert

3

El Martes, 5 de Enero de 2010, Robert K.
escribió:> the design level already.
Yes, you are right. I did a hack by creating a modification of
SyslogLogger
and then:

$stderr = SyslogLogger.new(“foo”)

However it’s really a hack since it’s just valid for “warn” method and
some
others using “$stderr.puts”. But the real stderr remains being
/dev/pts/N so
if the application raises it would write on the terminal.

Finally I’ve dropped the idea of using a Logger as $stderr.

Thanks.

4

On the other hand, that \n may come in handy in line-buffered I/O, and
leaves a clean start to the next and probably unrelated write.