Steve Grubb <sgrubb@redhat.com> wrote on 03/13/2006 09:14:22 AM:

> 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.

Wow, what I wrote is not what I mean. I should say that I am _not_ in favor of commas, I was trying to point out that spaces between fields (and only spaces), should be the way to go since its the most common form in our records and should therefore be made the only form for consistancy - not to mention all of the reasons you just listed. Sorry for not writing what I meant.

>
> > 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.

Again, I was not clear, although when I wrote this, I thought I was. I was saying I am in favor of chaning field names, such as "login uid", and replacing them with "login_uid". Amazing how much meaning can be lost between the reader and the writer. Normalizing records is good!

>
> > 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.

It isn't? From the code example that I read, although it does not have any documentation comments with it, leads me to believe my understanding to be correct. btw, you forgot to free your memory in that example! See the next comment for more.

>
> > 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.

OK, we've got a serious breakdown in communication here. Yes, I understand that ausearch_next_event will get you to the next event that matches your criteria. And I also understand that auPARSE_next_event will get you to the next event that falls in chronologial order (in terms of serial number or time stamp, whatever) and that is _not_ subject to any specified search criteria. However, my sole point was it would be good to state clearly that all other auparse_* functions, which concern themselves with parsing of records and fields, will do so based on the current event they are at, whether you got to it through an ausearch_next_event call or an auparse_next_event call.

Mike