[ZBX-21856] trigger / calculated expression regexp dot escape possible regression Created: 2022 Nov 03 Updated: 2024 Apr 10 Resolved: 2024 Jan 11 |
|
| Status: | Closed |
| Project: | ZABBIX BUGS AND ISSUES |
| Component/s: | Server (S) |
| Affects Version/s: | 6.2.4 |
| Fix Version/s: | None |
| Type: | Incident report | Priority: | Trivial |
| Reporter: | Marc Rumo | Assignee: | Andrejs Sitals (Inactive) |
| Resolution: | Duplicate | Votes: | 3 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
zabbix7420template.json
zabbixtemplateaddfail.png
|
||||||||
| Issue Links: |
|
||||||||
| Team: |  Team A |
||||||||
| Sprint: | S2401 | ||||||||
| Description |
|
Hello, I believe there is a regression with the regular expression syntax with something that I think used to work on 5.4 and no longer does on 6.4 when specifying the regular expression that matches the literal . (dot) character. As per regular expression traditional syntax, the . should be escaped with a \ backslash (otherwise it matches any character). But it doesn't seem to work. (A work around is to use [.], but well, the backslash syntax is still a regression)
Steps to reproduce create a calculated item with one of the four different formulas:
count(//agent.ping,#10,"regexp", "[.]")
returns 0, as expected
count(//agent.version,#10,"regexp", "[.]")
returns 10, as expected
count(//agent.version,#10,"regexp", "\\.")
returns 0 <- this is not expected, it should be 10, such as previous test
count(//agent.version,#10,"regexp", "\.")
rejected by frontend, which is expected behavior as per double escape rule
two formulas rightfully work one formula is rightly rejected one formula produces the unexpected result
|
| Comments |
| Comment by Oleksii Zagorskyi [ 2022 Nov 04 ] |
|
I had to format your description to be sure for formulas. |
| Comment by Marc Rumo [ 2022 Nov 04 ] |
|
Hello, Thank you for your reformatting. I can confirm that you did it correctly.
Best regards, |
| Comment by Jerimiah [ 2023 Jul 12 ] |
|
I think this may be more widespread than just a literal dot (\.). I'm also having trouble with other PCRE character type escapes like \d being rejected by the UI. For example: count(//agent.version,#10,"regexp","\d")
fails with: Invalid parameter "/1/params": incorrect expression starting from "count(//agent.version,#10,"regexp","\d")". This is the same result as the OP provided, though I think this is actually incorrect behavior. Further, the sequence \\. should match a literal backslash followed by any character, so count(//agent.version,#10,"regexp", "\\.")
should return 0, not 10 as the OP suggests. I have dozens of templates that use expressions containing \. and \d that are working fine, but if I attempt to add one of those templates to a host, I get an error. I also get an error when trying to create a new trigger expression containing them, so it may just be an issue with the UI validation. |
| Comment by Oleksii Zagorskyi [ 2023 Dec 22 ] |
|
Jerimiah, please show me a clean example what could not assign to a host which causes UI error. |
| Comment by Jerimiah [ 2023 Dec 22 ] |
|
Here is a screenshot of the error when applying an existing template to a host: And a JSON export of the template: This template is associated to other hosts and is working. These examples are from 6.4.1, which is the latest available on the download page for my platform. I appreciate you looking into this. Please let me know if I can provide any additional information that may help. |
| Comment by Andrejs Sitals (Inactive) [ 2024 Jan 11 ] |
|
6.0, 6.2 and 6.4 currently seem to work the same way - from the original issue description, all 4 formulas can be used in calculated items and all versions return the same results - 0, 10, 0 and 10. 7.0 will require "\" to be escaped, hence formula with "\ \." will return 10, while the last one will get rejected by the frontend. Jerimiah, as for your template - I was able to import it into the latest 6.4 and also pre-7.0. When importing into pre-7.0, backslashes were escaped by the import process. "Escaping examples" are now documented for different versions and different use cases - 6.0, 6.4 and 7.0. |
| Comment by Andrejs Sitals (Inactive) [ 2024 Jan 11 ] |
|
Closing as a duplicate of |
