custom facts sensitive to spaces

[Vince Skahan]

I think I found a bug in facter in 3.8.2 but wanted to ask here before opening a PL ticket.

Basic description is that facter has different behaviors if you run it without vs. with a fact specified.

To recreate:

# echo 'foo = bar' > /etc/facter/facts.d/foo.txt
# facter | grep foo
foo  =>  bar
# facter foo

#

Net effect is that if you have spaces around the = sign in your custom fact definitions, the server doesn't match at all.  It seems to look up by name, which returns nothing (or a blank line, or a space - it's hard to tell which)

Workaround is to have no spaces around the = sign, but I think this is a bug needing fixing.  The behavior should be the same when you run "facter | grep foo" and "facter foo" shouldn't it ?

[Christopher Wood]

On Tue, Sep 08, 2015 at 11:47:44AM -0700, Vince Skahan wrote:
> I think I found a bug in facter in 3.8.2 but wanted to ask here before
> opening a PL ticket.
>
> Basic description is that facter has different behaviors if you run it
> without vs. with a fact specified.
>
> To recreate:
>
> # echo 'foo = bar' > /etc/facter/facts.d/foo.txt
> # facter | grep foo
> foo  =>  bar
> # facter foo

The structured fact documentation does not have spaces between the fact name, the equals sign, and the fact value.

https://docs.puppetlabs.com/facter/2.4/custom_facts.html#structured-data-facts

I get the correct behaviour when I rename the fact file with the space in its name implied by the string 'foo = bar'. By using the space it appears you have created a fact named 'foo ' rather than 'foo'. You see that the value of the fact has a space in it too.

[root@cwh facts.d]# echo 'fact1 = foo' >fact1.txt
[root@cwh facts.d]# facter | grep fact1
fact1 => foo
[root@cwh facts.d]# facter | grep processorcount
physicalprocessorcount => 1
processorcount => 4
[root@cwh facts.d]# facter fact1

[root@cwh facts.d]# mv fact1.txt 'fact1 '.txt
[root@cwh facts.d]# ls -l fact1\ .txt
-rw-r--r-- 1 root root 12 Sep 8 16:14 fact1 .txt
[root@cwh facts.d]# facter 'fact1 '

foo

> #
> Net effect is that if you have spaces around the = sign in your custom
> fact definitions, the server doesn't match at all.  It seems to look up by
> name, which returns nothing (or a blank line, or a space - it's hard to
> tell which)
>
> Workaround is to have no spaces around the = sign, but I think this is a
> bug needing fixing.  The behavior should be the same when you run "facter
> | grep foo" and "facter foo" shouldn't it ?
>

> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [1]puppet-users...@googlegroups.com.
> To view this discussion on the web visit
> [2]https://groups.google.com/d/msgid/puppet-users/f56bf1f3-4d68-4c10-a662-ff578b0668dc%40googlegroups.com.
> For more options, visit [3]https://groups.google.com/d/optout.
>
> References
>
> Visible links
> 1. mailto:puppet-users...@googlegroups.com
> 2. https://groups.google.com/d/msgid/puppet-users/f56bf1f3-4d68-4c10-a662-ff578b0668dc%40googlegroups.com?utm_medium=email&utm_source=footer
> 3. https://groups.google.com/d/optout

[Josh Cooper]

I think you're running into https://tickets.puppetlabs.com/browse/FACT-1050

Josh 

[Vince Skahan]

On Wednesday, September 9, 2015 at 12:01:54 AM UTC-7, Josh Cooper wrote:

I think you're running into https://tickets.puppetlabs.com/browse/FACT-1050

Looks like the same thing to me.
It should left+right strip spaces around the '=' sign in all cases.

I did notice that 'facter' with no arguments does show the spaces, you just need a font that lets you notice it's there.
Again, I ran into it on 3.8.2

Thanks....

[Christopher Wood]

On Wed, Sep 09, 2015 at 12:01:54AM -0700, Josh Cooper wrote:

(SNIP)

> I think you're running into
> https://tickets.puppetlabs.com/browse/FACT-1050
> Josh 

There's a big "should" question here, maybe the desired behaviour needs to be nailed down before that's a bug?

For instance, whitespace before/after the "=" could be, according to functionality I've seen:

a single ascii " "
things described by the PCRE \s+ (includes tabs)
unicode versions of space characters
whatever Word was using for a space character that day

Apart from nailing down how it "should" behave, there's the can of worms that troubleshooting whitespace opens. It's way easier to explain how things before the '=' are the key, and things after the '=' are the value.

(Editorially, I feel I've served my time troubleshooting allegedly insignificant whitespace. Way before I started with puppet though.)

> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [1]puppet-users...@googlegroups.com.
> To view this discussion on the web visit

> [2]https://groups.google.com/d/msgid/puppet-users/377b6326-f854-4a9d-9ea0-f48576098273%40googlegroups.com.

> For more options, visit [3]https://groups.google.com/d/optout.
>
> References
>
> Visible links
> 1. mailto:puppet-users...@googlegroups.com

> 2. https://groups.google.com/d/msgid/puppet-users/377b6326-f854-4a9d-9ea0-f48576098273%40googlegroups.com?utm_medium=email&utm_source=footer
> 3. https://groups.google.com/d/optout

[Vince Skahan]

On Wednesday, September 9, 2015 at 8:27:42 AM UTC-7, Christopher Wood wrote:

There's a big "should" question here, maybe the desired behaviour needs to be nailed down before that's a bug?

For instance, whitespace before/after the "=" could be, according to functionality I've seen:

a single ascii " "
things described by the PCRE \s+ (includes tabs)
unicode versions of space characters
whatever Word was using for a space character that day

I can't think of a case I've ever seen where where "key = value" is supposed to be interpreted as anything different than "key=value", but sure documenting expected behavior is always goodness.