Rudder

It seems that a directive created from the File content(key/value format) allows any amount of space and tab characters after the keyword and BEFORE the separator but not after it, or else it considers it non-compliant. For example:

If the keyword is COLOR, the separator is an equals sign (=), and the value is BLUE, then we have:

\t=tab character

COLOR=BLUE (result compliant)
COLOR =BLUE (result compliant)
COLOR =BLUE (result compliant)
COLOR\t=BLUE (result compliant)
COLOR\t =BLUE (result compliant)
COLOR\t \t=BLUE (result compliant)
COLOR \t =BLUE (result compliant)
COLOR \t=BLUE (result compliant)

COLOR= BLUE (result non-compliant)
COLOR= BLUE (result non-compliant)
COLOR=\tBLUE (result non-compliant)
COLOR= \tBLUE (result non-compliant)
COLOR=\t BLUE (result non-compliant)
COLOR=\t \tBLUE (result non-compliant)
COLOR= \t BLUE (result non-compliant)

Basically, any whitespace between the separator and the value causes the key/value pair to be considered non matching.

This is also true when the separator itself is a space as in the use of the variable ${ncf_const.s}

This makes it very difficult to determine whether a key/value pair is already compliant from an audit perspective, since the amount of whitespace before and after the separator doesn't matter for a lot of config files in linux, and is considered valid.

In some cases however, I could see that for some files, any whitespace before or after the separator should be considered non-compliant.

As a suggestion, you could add a checkbox to indicate a STRICT match (that is no whitespace allowed on either side), that would override a reasonable default of any amount of whitespace allowed on either side of the separator (especially when the separator itself is a space character).