Checking a variable is not 'undef'

[Chris Cowley]

OK, so what it the recommended way to do this? Somehow it is not something I have come up against before, I have the impression that it is a lot harder than simply:

if $variable {
  do stuff
}

I've had a look through stdlib and it does not seem to have anything that helps here (if that is the case, then I will make a feature request).

[Matthew Haughton]

As noted at http://docs.puppetlabs.com/puppet/latest/reference/lang_datatypes.html#undef, "When used as a boolean, undef is false."

So you can definitely use an if statement that way.

[José Luis Ledesma]

But also and empty variable is false.

When I just one to check undef I do

if $var!=undef {
  Do stuff
}

--
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 puppet-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/34d13e56-6c1b-40be-bfb1-ebf0780fd05e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Henrik Lindberg]

On 2014-11-07 16:38, Chris Cowley wrote:
> OK, so what it the recommended way to do this? Somehow it is not
> something I have come up against before, I have the impression that it
> is a lot harder than simply:
>
> if $variable {
> do stuff
> }
>

In version before Puppet 4.0.0 the values as boolean map like this:

"falsey": empty string, false, undef
"truthy": everything else

In Puppet 4.0.0 this will be:

"falsey": false, undef
"truthy": everything else

In Puppet < 4.0.0, an undef is considered to be equal (==) to an empty
string. In 4.0.0 this will no longer be the case and only undef is undef
when comparing and checking equality.

Thus, if you want to check if a value is undef (but you do not want to
match empty strings) you must jump through hoops to do this using
something that does not equate undef with "", such as the 'in' operator.
(Note that the undefined value must be placed in the array, it cannot
appear on the left hand side as this raises an error the left side is
not a String (in versions before 4.0.0).

if $x == undef and !("" in [$x])
# do something, $x is undef and not deliberately set to empty string
end

This will continue to work in 4.0.0 (even if undef and "" are not
considered to be the same. (The reason this works is because there are
bugs in the implementation of "in" that does not equate undef with "") -
that behavior will not be changed.

Regards
- henrik

> I've had a look through stdlib and it does not seem to have anything
> that helps here (if that is the case, then I will make a feature request).
>

> --
> 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 puppet-users...@googlegroups.com

> <mailto:puppet-users...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/puppet-users/ac5be1c4-073a-404b-969d-14b53267cf7a%40googlegroups.com
> <https://groups.google.com/d/msgid/puppet-users/ac5be1c4-073a-404b-969d-14b53267cf7a%40googlegroups..com?utm_medium=email&utm_source=footer>.

> For more options, visit https://groups.google.com/d/optout.

--

Visit my Blog "Puppet on the Edge"
http://puppet-on-the-edge.blogspot.se/

[Felix Frank]

On 07/13/2014 03:36 AM, Henrik Lindberg wrote:
> "falsey": empty string, false, undef
> "truthy": everything else
>
> In Puppet 4.0.0 this will be:
>
> "falsey": false, undef
> "truthy": everything else

Oops? Interesting. This will break O(50%) of my manifests. Good to know,
seeing as there is likely no deprecation warning for "you are apparently
using an empty string in boolean context", right?

[Henrik Lindberg]

Yes, no deprecation issued as that would create an avalanche of
deprecations.
Best approach is to test with --parser future.

- henrik

[José Luis Ledesma]

From my point of view is better a warning when a empty string is taken as a false, than some configuration applied erroneously once upgraded to 4.0

--
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 puppet-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/lpuca7%249ap%241%40ger.gmane.org.

[Henrik Lindberg]

On 2014-13-07 22:58, José Luis Ledesma wrote:
> From my point of view is better a warning when a empty string is taken
> as a false, than some configuration applied erroneously once upgraded to 4.0
>

We encourage testing with 3.7 future parser. If it turns out to be a
problem for many (breakage due to undef/'' change) we will see what we
can do about it. We are not sure we can find and efficiently check all
occurrences as it involves reporting all places where an undef was not
turned into a string that is passed off to logic that may or may not
compare it to a Boolean. (This is the very essence of the problem; not
knowing if something is a defined string or not later in the evaluation).

I can also highly recommend using rspec-puppet and writing catalog unit
tests to ensure that your catlogs do not regress (because of changes in
Puppet, changes in modules you use, or indeed changes in your own modules).

Regards
- henrik

> El 13/07/2014 18:32, "Henrik Lindberg" <henrik....@cloudsmith.com

> <mailto:henrik....@cloudsmith.com>> escribió:

>
> On 2014-13-07 14:57, Felix Frank wrote:
>
> On 07/13/2014 03:36 AM, Henrik Lindberg wrote:
>
> "falsey": empty string, false, undef
> "truthy": everything else
>
> In Puppet 4.0.0 this will be:
>
> "falsey": false, undef
> "truthy": everything else
>
>
> Oops? Interesting. This will break O(50%) of my manifests. Good
> to know,
> seeing as there is likely no deprecation warning for "you are
> apparently
> using an empty string in boolean context", right?
>
>
> Yes, no deprecation issued as that would create an avalanche of
> deprecations.
> Best approach is to test with --parser future.
>
> - henrik
>
> --
>
> Visit my Blog "Puppet on the Edge"

> http://puppet-on-the-edge.__blogspot.se/

> <http://puppet-on-the-edge.blogspot.se/>
>
> --
> 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 puppet-users+unsubscribe@__googlegroups.com
> <mailto:puppet-users%2Bunsu...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/__msgid/puppet-users/lpuca7%__249ap%241%40ger.gmane.org
> <https://groups.google.com/d/msgid/puppet-users/lpuca7%249ap%241%40ger.gmane.org>.
> For more options, visit https://groups.google.com/d/__optout
> <https://groups.google.com/d/optout>.

>
> --
> 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 puppet-users...@googlegroups.com
> <mailto:puppet-users...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/puppet-users/CAF_B3dda_ij%2B8HCi%3DRMCv_e2gx-%2BMYraB7nPByddMZDpCL9Eyg%40mail.gmail.com
> <https://groups.google.com/d/msgid/puppet-users/CAF_B3dda_ij%2B8HCi%3DRMCv_e2gx-%2BMYraB7nPByddMZDpCL9Eyg%40mail.gmail.com?utm_medium=email&utm_source=footer>.

> For more options, visit https://groups.google.com/d/optout.

[Felix Frank]

On 07/14/2014 05:07 PM, Henrik Lindberg wrote:
>> From my point of view is better a warning when a empty string is taken
>> as a false, than some configuration applied erroneously once upgraded
>> to 4.0
>>
>
> We encourage testing with 3.7 future parser. If it turns out to be a
> problem for many (breakage due to undef/'' change) we will see what we
> can do about it. We are not sure we can find and efficiently check all
> occurrences as it involves reporting all places where an undef was not
> turned into a string that is passed off to logic that may or may not
> compare it to a Boolean. (This is the very essence of the problem; not
> knowing if something is a defined string or not later in the evaluation).

The warning would also cause a false sense of security - just because
your *current* manifest and data are clean of "" == false assumptions,
it's not assured that there are no lurking conditionals that are prone
to break once a node has a change to its data or facts, or a new node
with such data appears.

There will be no alternative but to carefully review our code before the
Puppet 4 upgrade. Checking for catalog differences from the future
parser will help, too.

Cheers,
Felix