The Puppet Labs Issue Tracker has Moved: https://tickets.puppetlabs.com

Bug #13952

'false' matches . but not false or default.

Added by Jos Boumans over 2 years ago. Updated about 2 years ago.

Status:Needs DecisionStart date:04/15/2012
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:language
Target version:-
Affected Puppet version:2.6.16 Branch:
Keywords:

We've Moved!

Ticket tracking is now hosted in JIRA: https://tickets.puppetlabs.com

This ticket may be automatically exported to the PUP project on JIRA using the button below:


Description

See the below script. In my opinion the right order of evaluation here would be: 1) A direct lookup – in this case, the key ‘false’ 2) Any regular expressions – order is up in the air; declaration order perhaps? 3) default – if all else fails, that should be the right answer.

Note, that in my opinion, false should definitely NOT match /./.

# cat false.pp 
$x = false
$y = $x ? {
/./ => 1,
false => 2,
default => 42,
}
notice( $x )
notice( $y )
# puppet apply false.pp 
notice: Scope(Class[main]): false
notice: Scope(Class[main]): 1

History

#1 Updated by Anonymous over 2 years ago

  • Category set to inventory service
  • Status changed from Unreviewed to Needs Decision
  • Assignee set to Anonymous

This is still true in Telly as it stands today. Pieter, I think you are the best placed person to drive the decision about what should happen here, and how it works. (Ultimately, this is because there are only strings in Puppet, not other data types, no matter how much it kind of looks like there are – or, at least, how we stringify types in a liberal fashion.)

#2 Updated by Anonymous over 2 years ago

  • Category changed from inventory service to language

#3 Updated by Henrik Lindberg about 2 years ago

Agree, a boolean value can not be matched with a regular expression. The Puppet DSL makes a distinction between false and “false” (the later is not boolean false, and neither is “true”).

This is a bug IMO.

Also available in: Atom PDF