Why does "warn" print a extra \n ?

[Iñaki Baz Castillo]

Hi, by redirecting $stderr to a logger (Logger or SyslogLogger instance) I'=
ve=20
realized that Kernel#warn prints an extra \n so the logger is called twice=
=20
(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.




=2D-=20
I=C3=B1aki Baz Castillo <[email protected]>

 

[Robert Klemme]

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

Kind regards

robert

 

[Iñaki Baz Castillo]

El Martes, 5 de Enero de 2010, Robert Klemme escribi=F3:

Frankly, I believe redirecting stderr to a logger instance is a broken=20
approach. Why? A logger has a completely different interface, i.e. it=20
accepts at least a log level and the message to log. Based on that it=20
decides whether to output the message and how to format it. A stream=20
like stderr readily accepts anything send to it and it will output it=20
(if there are no errors of course). There is no formatting or deciding=20
going on.
=20
I do not know your use case or what you want to achieve with this but it= =20
seems redirecting a stream of bytes to a logger is not a good idea on=20
the design level already.

Yes, you are right. I did a hack by creating a modification of SyslogLogger=
=20
and then:

$stderr =3D SyslogLogger.new("foo")

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

=46inally I've dropped the idea of using a Logger as $stderr.

Thanks.


=2D-=20
I=F1aki Baz Castillo <[email protected]>

 

[Xavier Noria]

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.