Relevance parsing a file

Content Authoring
1

(imported topic written by SystemAdmin)

Need some help with relevance statements to parse a comma or : delimited file

I can format the file in any way that would be easier for bigfix.

uxfit344,1.19,1.06,1.20,1.4.11.43,enabled

or

uxfit344

B:1.19

D:1.06

S:1.20

C:1.4.11.43

E:enabled

I need to check the version of 4 different firmware levels and the enabled/disabled state.

I would like to compare the version number in this file to a set level a system should be at, or take action to upgrade them.

Thanks in advance…

2

(imported comment written by NoahSalzman)

This should get you started:

q: lines of file “c:\foo.txt”

A: uxfit344

A: B:1.19

A: D:1.06

A: S:1.20

A: C:1.4.11.43

A: E:enabled

q: lines whose (it contains “B:”) of file “c:\foo.txt”

A: B:1.19

q: following texts of firsts “:” of lines whose (it contains “B:”) of file “c:\foo.txt”

A: 1.19

q: (following texts of first “B:” of lines of it, following texts of first “E:” of lines of it) of file “c:\foo.txt”

A: 1.19, enabled

3

(imported comment written by SystemAdmin)

So if I use the following in a task relevance in order execute an action script, I need to compare a version.

q: lines of file “c:\foo.txt”

A: uxfit344

A: B:1.19

A: D:1.06

A: S:1.20

A: C:1.4.11.43

A: E:enabled

q: following texts of firsts “:” of lines whose (it contains “B:”) of file “c:\foo.txt”

A: 1.19

What relevance statement would I use to take action on all hosts not at version 1.20 using the above example of a host at installed version 1.19 in foo.txt

4

(imported comment written by NoahSalzman)

You turn the result into a “version” and then do a check to see if it is at the version level you want. Here are some examples. I confused by the 1.19.1 result – perhaps it only checks major.minor by design and ignores the second dot?

q: (following texts of firsts “:” of lines whose (it contains “B:”) of file “c:\foo.txt”) as version

A: 1.19

q: ((following text of firsts “:” of lines whose (it contains “B:”) of file “c:\foo.txt”) as version) < (“1.20” as version)

A: True

q: ((following text of firsts “:” of lines whose (it contains “B:”) of file “c:\foo.txt”) as version) < (“1.18” as version)

A: False

q: ((following text of firsts “:” of lines whose (it contains “B:”) of file “c:\foo.txt”) as version) < (“1.19.1” as version)

A: False

q: ((following text of firsts “:” of lines whose (it contains “B:”) of file “c:\foo.txt”) as version) < (“1.18.9” as version)

A: False

q: ((following text of firsts “:” of lines whose (it contains “B:”) of file “c:\foo.txt”) as version) < (“1.20.3” as version)

A: True

5

(imported comment written by SystemAdmin)

Noah,

Yeah, there needs to be an equal number of levels on both sides of the version comparison. E.g. 1.2 < 1.3, 1.9.0 < 1.9.4, 8.7.3.2 < 9.8.2.1 That’s why that 1 comparison came back as false.

Granted, I’d argue that the BF inspectors should automatically pad 2 version objects that’s being compared. Maybe one of your developers can explain why this happens. Maybe there’s a reason why it’s not automatic?

So to keep things easy, you’d need to pad his version numbers from the file so it’s in the format of major.minor.revision.build

Stick “pad of” in front, and make sure the right version number being compared has 4 places (stick an extra “.0” at the end). Then the comparison works fine.

pad of ((following text of firsts “:” of lines whose (it contains “B:”) of file “c:\foo.txt”) as version) < (“1.19.1.0” as version)

Paul