> > So when it hits the parser, the is no such thing like a HT present > anymore. > > What we could do, however, is add an option that tells the sanitizer > to > > replace HT by SP in all cases. > > this is not as good because the tabs are useful in the message itself, > it > acts as a field seperator for the different fields from the windows > logs, > and the fields themselves can contain spaces, so if you replace them > with > tabs you no longer have any way to identify individual fields. > > the parser could look for # (which is not a valid character in a > hostname, > and I don't think it's valid in a tag), then if it's #011 treat is as a > space for seperating the hoatname/tag/message and if it's anything > else, > make that the start of the message.
Yeah, but (not only because it is snare ;)) wouldn't it be the right thing to do to fix the broken sender? Of course, I can add another exception AND "#" may validly be inside a tag. I am all for trying to guess right, but keep in mind that all this also has a performance toll. One of my plans is to add a custom parser interface. With it, custom parsers could be added and they could take care of all the anomalies of the real world (and there *are* many!). But that is up for another increment, after the queue work. I don't like to change the parsers that have proven to work well in practice just because one application misbehaves... Rainer _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com
