Mordechai T. Abzug on Sun 27/08 16:24 -0400:
I've just comitted a fix, it should be available in the next version, or apply this patch:
+ for (oldsrc = src, oldleft = left; oldleft; oldleft--, oldsrc++) { + if (*oldsrc < 32) *oldsrc = '.'; + }
Thanks! But since other syslogd implementations (IMLE) leave the other control characters alone and just replace newlines with spaces, wouldn't it be more correct to do exactly that, in the spirit of full compatibility?
This is not true. The Linux (and I believe it is derived from BSD) syslogd turns eg ASCII 13 to a "^M" string. This screws up parsing because some programs log continuation lines delimited with tabs, and instead of incurring a split to new message, it just gets thrown in as "^I" (two chars). This contradicts Solaris' syslogd behavior, which is to put them through unchanged. Although I sort of agree that only printables 32-126 decimal should be embedded in log files. But that certainly doesn't make you i18n :) Incidentally is there any sort of RFC for syslog messages? I've not been able to locate any. The only way I can figure it out is by reading other syslogd implementations. It seems they delimit messages by ASCII NULs and prefix new messages with a "<xx>" number which when masked gives facility and priority. -- Questra Desktop and Network services (QDN) | (716) 381-0292 x525 web: http://qweb.web.roc.questra.com/srs/ | techserv@questra.com