On Wed, 26 Jan 2011, Rainer Gerhards wrote:
-----Original Message-----
From: [email protected] [mailto:[email protected]]
On Tue, 25 Jan 2011, Rainer Gerhards wrote:
On 01/17/2011 07:22 PM, [email protected] wrote:
Attached is a test file to test various modes of imfile, the results
of
the test, and a consolodated patch going back to
f7c20920046ebcb94eadadf1ebad97b634a12a2d (your merge of the other
imfile
fixes)
I have merged this as well now. Please re-check, but I think it is
OK. I will
merge this into v5-devel tomorrow if I don't hear anything against
that :)
I will test this today. did you include the test file and make a unit
test
for this?
I have to admit I did not get that you wanted me to do that ;) Will see that
I add a testcase later today.
no problem, I never said anything explicitly, but I had sent you a test
file and the expected output. Since you are so aggressive about having
test cases for everything, I assumed that you would want one for this as
well.
I just compiled it and will test it in the next few min.
One thing that surprised me is that it doesn't appear that control
characters in imfile are escaped the way that network received logs
are
escaped. Did I miss some way to enable this? Initially I thought
that
possibly only \n wasn't escaped, but some of my mistakes generated
other
control characters.
I guess this issue simply never came up. The way imfile works, it
needs to do
the sanitazion itself. Because that would happen in the parsing step,
but
imfile data can not be run through the parser.
Ok, I'll do some digging and find the routine that's called to do the
sanitizing and see if we can just add a call to the existing code.
I probably makes sense to expose this function as a callable API (especially
as it needs some update to be more Unicode-friendly). Will put this on the
list as well.
Ok, in that case I will wait on investigating this
Side-Note: I will also see that I merge some fixes from older releases in
today. This can be a bit more time-consuming due to interface changes.
sounds good. I will probably generate a AIX fixup parser today or tomorrow
as well (very similar to the cisco one, it detects and removes a chunk of
text from the log before 'failing' through to the default parser)
David Lang
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com