Re: Audit Parsing Library Requirements
On Monday 13 March 2006 09:35, Michael C Thompson wrote:
I know this is not likely to change, but is there a reason why we
don't
have a common delimiter?
Personally, I think its a bad idea since it makes the text "darker". Spaces
make it lighter and more pleasing to the eye. Its too later to make these
kind of changes.
Removing inconstancies in the records, such as using '_' in
place of spaces
in field names and removing these commas, would seem like a good thing to
do, but before anyone does that work, will making that change be acceptable
from a code point of view?
I would like to fix inconsistencies, but I don't consider '_' to be an
inconsistency. I would be hesitant to make any other changes besides
normalizing records. Its unnecessary and unwanted.
Although it is clear from the code example (and I am sure this is
not
going to be the final version of the document, it would probably be nice
to mention that auparse will, when not using auparse_next_event, will be
parsing the record that was found (and is current being pointed to) by
ausearch_* functions, for example.
But this is not true.
Your comment in the above, "without regard to any search options
that may be
in effect", is somewhat befuddling on this point.
OK, you put in a search for uid=500. ausearch will find events that have a
match. You should call ausearch functions to walk these events. So, for
example, the cursor goes to event 150 on first call, then event 200 next
call. If you auparse, then it will go to the next event which could be 201.
This is all common database techniques. One is based off an index and the
other is sequential access
-Steve