[BusyBox] init syslog messages have ^M

[Paul Fox]

 > 
 > I've been noticing that when init sends entries to syslog, it sticks a 
 > ^M at the front of the message.  I don't see any other processes doing 
 > this, and looking in init.c I can't see why this is happening.
 > 
 > Dec 31 18:00:28 init: ^MStarting pid 225, console /dev/ttyS0: '/bin/getty'
 > 
 > Anyone else seeing this, or is it just me?
 > 

i reported this a couple of weeks ago -- see below.  the ^M is a
result of the lines that i quoted.  i didn't follow up.  the
extra carriage return is being added so explicitly, i kind of
expected someone to respond with "it's that way because of X". 
but no one responded -- maybe "X" doesn't exist, and it's simply
a bug.

paul
=---------------------
 paul fox, pgf at brightstareng.com

 > Date:    Thu, 11 Nov 2004 14:09:48 EST
 > To:      busybox at mail.codepoet.org
 > From:    Paul Fox <pgf at brightstareng.com>
 > Subject: init: leading '\r' in log messages?
 > ===============
 > 
 > hi -- 
 > 
 > can anyone tell me why init adds a carriage return to the start
 > of all of its logged messages?  the code in message() looks
 > like:
 >     
 > 	msg[0] = '\r';
 > 		va_start(arguments, fmt);
 > 	l = vsnprintf(msg + 1, sizeof(msg) - 2, fmt, arguments) + 1;
 > 		va_end(arguments);
 > 
 > i understand the aesthetics of having one's output start in
 > column 0, but this may cause a tty log or a screen capture to
 > lose information, if init's message comes out on top of a
 > partially completed line of text.  and in syslog output (or, at
 > least, in the output of logread) it just looks bad, since at some
 > point in the process it gets printified into "^M":
 > 
 >     Jan  1 00:00:26 mybox daemon.info init: ^MStarting pid 562, ...
 > 
 > my opinion is that the leading '\r' should go away completely.
 > if not, i think it should at least be removed from the syslog path.
 > 
 > (the only reason i can think of for leaving it is if it's necessary
 > to full some heuristic in syslog that's trying to decide what
 > sort of a message it's dealing with -- there's code there that
 > guesses at the precence of a timestamp, for instance.  but this
 > is conjecture.)
 > 
 > paul
 > =---------------------
 >  paul fox, pgf at brightstareng.com