Well, no. This is not illogical, just not familiar to you, that's all. We're not dealing with a shell script, but a highly-specific configuration file.
I agree, it is logical (in its own twisted way ;-). I assume the whole parameter is grabbed as a block and parsed afterwards. I remember some unusual parsing with big brother because of it operating out of the shell environment, perhaps this has grown out of that....
The quoting is consistent across Xymon configuration files.
Well not in this case, eg in analysis.cfg: DISK "/yada bing bong" 90 95 it isn't "DISK /yada bing bong". Same in hosts.cfg: 0.0.0.0 whatever.com.au # NAME:"What Ever" not: "NAME:What Ever".
thanks for your help and your work with xymon. It is a great system.
cheers, Phil
On 6 March 2013 11:04, Phil Crooker <Phil.Crooker at orix.com.au> wrote:
Thanks, it does work on ignore statements with regular expressions but not with simple strings:
LOG eventlog_application %^warning COLOR=yellow "IGNORE=No externals have been specified" LOG eventlog_application %^warning COLOR=yellow IGNORE="No externals have been specified"
I would have thought both of these would work. Might be a bug.
If I escape the spaces or if I add the %, it works.
Well that's something.
But still, this is not logical - quotes are normally after the equal sign
Well, no. This is not illogical, just not familiar to you, that's all. We're not dealing with a shell script, but a highly-specific configuration file. The quoting is consistent across Xymon configuration files.
But the fact that the quoted string with spaces doesn't match is probably a bug.
and of course it shouldn't be necessary to make this into a regex when it isn't.
That's true.
Cheers Jeremy