^M
, or 015, is a "CR" in ASCII. What you're missing is linefeeds (^J
012).
However, it is unusual for syslog output to use CRs like that. Logging over the network does not use any particular line endings – the client is required to send one message per UDP datagram, or to explicitly specify the message length when using stream transports. The messages only get line separators added when they're written out to /var/log
, so if your /var/log/messages
were lacking LFs, it would be your syslogd that was broken.
But that is not the case, since you say in your comment that "it shows ^M literally". tail
does not translate CRs to ^M
, it just dumps data to stdout. Instead, it could be that your device does send multiple lines per datagram, and your syslog daemon translates them to a literal ^
+ M
sequence when writing the log files. (I have rsyslogd here, it converts a CR to #015
.)
In other words, your device does not follow the syslog protocol.
You can use the following to convert such a "^M
" sequence to a real Unix newline (a LF):
sed 's/\^M/\n/g'
(If you want CR+LF's, use \r\n
.)
^M
or#015
, or do they just get printed on the same line? – grawity Feb 10 '12 at 14:32^M
literally – Pablo Feb 10 '12 at 14:33