The syntax specification in doc/userManual.rst is unclear
Current version
rule: Term|Operant Operand Operator
Term: <Operand> <Operand> <Operator>
Operand: Process | Event | Value
Event: .event.
Process: .process.
Value: number|string
Operator: EQ|LT|LE|GT|GE|STRCMP|AND|OR
: see chapter of corresponding filter type
Ok it does not really use a standard notation like BNF. But would help if you agree at least to common capitalization for the non-terminals. (like Rule not rule)
line 1: "rule: Term|Operant Operand Operator" I assume "Operant" to be a typo? Then bracketing is not fully clear, I assume that you want to say that instead of the first Operand you can also have a term? (So something like "1 1 EQ 1 EQ" can be parsed as a rule)
line 2: On the right side you use <> around the elements on the right side, but <Operand>, or <Operator> is not really clear, when on the first line you don't use <> (if you switch to BNF then al non-terminals would be enclosed by <>)
Also in optimistic interpretation this syntax does not allow for complex filter expressions. Like ".event.classification 4 EQ .event.severity 3 LE AND" that you mention below. In this expression there is a Term followed by Term followed by an Operator. This does not parse as a Rule, because a Rule cannot have two terms.
I was not able to reconstruct the syntax from the code. But I would assume that it should be something like this:
Suggested syntax:
Rule: Term | Rule Rule Operator
Term: Operand Operand Operator
Operand: Process | Event | Value
Event: .event.
Process: .process.
Value: number|string
Operator: EQ|LT|LE|GT|GE|STRCMP|AND|OR
This would explain that
elosc -s "1 1 EQ 1 1 EQ LT 1 1 EQ LT"
parses successfully (matches everything, obviously false is LT true).
On the other hand it does not explain that
elosc -s "1"
parses successfully (seems not to match any event). For this you would need to allow a single value as Rule, for example extending the Term.
Term: Operand Operand Operator | Value
Below in the documentation you mention also the filter ".process.uid 0 EQ process.gid EQ AND". This does not parse. I assume a value is missing before the second EQ.
The syntax specification in doc/userManual.rst is unclear
Current version
rule: Term|Operant Operand Operator
Term: <Operand> <Operand> <Operator>
Operand: Process | Event | Value
Event: .event.
Process: .process.
Value: number|string
Operator: EQ|LT|LE|GT|GE|STRCMP|AND|OR
: see chapter of corresponding filter type
Ok it does not really use a standard notation like BNF. But would help if you agree at least to common capitalization for the non-terminals. (like Rule not rule)
line 1: "rule: Term|Operant Operand Operator" I assume "Operant" to be a typo? Then bracketing is not fully clear, I assume that you want to say that instead of the first Operand you can also have a term? (So something like "1 1 EQ 1 EQ" can be parsed as a rule)
line 2: On the right side you use <> around the elements on the right side, but <Operand>, or <Operator> is not really clear, when on the first line you don't use <> (if you switch to BNF then al non-terminals would be enclosed by <>)
Also in optimistic interpretation this syntax does not allow for complex filter expressions. Like ".event.classification 4 EQ .event.severity 3 LE AND" that you mention below. In this expression there is a Term followed by Term followed by an Operator. This does not parse as a Rule, because a Rule cannot have two terms.
I was not able to reconstruct the syntax from the code. But I would assume that it should be something like this:
Suggested syntax:
Rule: Term | Rule Rule Operator
Term: Operand Operand Operator
Operand: Process | Event | Value
Event: .event.
Process: .process.
Value: number|string
Operator: EQ|LT|LE|GT|GE|STRCMP|AND|OR
This would explain that
elosc -s "1 1 EQ 1 1 EQ LT 1 1 EQ LT"
parses successfully (matches everything, obviously false is LT true).
On the other hand it does not explain that
elosc -s "1"
parses successfully (seems not to match any event). For this you would need to allow a single value as Rule, for example extending the Term.
Term: Operand Operand Operator | Value
Below in the documentation you mention also the filter ".process.uid 0 EQ process.gid EQ AND". This does not parse. I assume a value is missing before the second EQ.