Issue #14094 has been updated by Daniel Pittman.

Status changed from Unreviewed to Accepted

Ruby at 1.8.7 and earlier don't actually *support* any sort of blank object.  
They always mix in kernel.  Which is awesome, because fundamental parts of Ruby 
(eg: raise) are implemented with those methods.  That is totally awesome.

The real fix is almost certainly to use a template system that doesn't just 
randomly embed Ruby, or at least that has additional and useful preprocessing 
between the template DSL and Ruby evaluation, so we can replace "you did 
something that looks like a method invocation" with "rewrite a variable access 
in our template language into an actual variable lookup".
----------------------------------------
Bug #14094: there are many methods on the template binding that prevents 
certain variables from being used
https://projects.puppetlabs.com/issues/14094#change-61119

Author: R.I. Pienaar
Status: Accepted
Priority: Normal
Assignee: 
Category: 
Target version: 
Affected Puppet version: 
Keywords: 
Branch: 


The template wrapper has a bunch of the usual suspect methods:

<pre>
% puppet -e 'notice(inline_template("<%= methods.sort.inspect %>"))'
notice: Scope(Class[main]): ["==", "===", "=~", "__id__", "__send__", "alert", 
"all_tags", "assert_that", "b64encode", "class", "class_def", "classes", 
"clone", "crit", "debug", "decode64", "decode_b", "display", "dup", "emerg", 
"encode64", "enum_for", "eql?", "equal?", "err", "execfail", "execpipe", 
"extend", "file", "file=", "freeze", "frozen?", "has_variable?", "hash", "id", 
"info", "inspect", "instance_eval", "instance_exec", "instance_of?", 
"instance_variable_defined?", "instance_variable_get", "instance_variable_set", 
"instance_variables", "is_a?", "kind_of?", "meta_def", "meta_eval", 
"meta_undef", "method", "method_missing", "methods", "nil?", "notice", 
"object_id", "private_methods", "protected_methods", "public_methods", 
"respond_to?", "result", "returning", "scope", "scope=", "send", 
"singleton_class", "singleton_methods", "string", "string=", "tags", "taguri", 
"taguri=", "taint", "tainted?", "tap", "threadlock", "to_a", "to_enum", 
"to_json", "to_pson", "to_s", "to_yaml", "to_yaml_properties", "to_yaml_style", 
"to_zaml", "type", "untaint", "warning", "yaml_property_munge", 
"zamlized_class_name"]
</pre>

Which if a user mere to try and use any of these in his template would yield 
weird results:

<pre>
% FACTER_err="foo" puppet -e 'notice(inline_template("<%= err %>"))' 
/usr/lib/ruby/site_ruby/1.8/puppet/util.rb:77: warning: multiple values for a 
block parameter (0 for 1)
</pre>

This is quite unexpected, a perfectly legit variable in a puppet manifest is 
suddenly unusable in a template in a weird way

This comes up quite regularly on #puppet, not sure what the best thing is here 
but some kind of Blank Slate style class might be a solution

tested against 2.6 and master


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Bugs" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

Reply via email to