Spacing in attributes

21 views
Skip to first unread message

zerozer...@gmail.com

unread,
Jan 20, 2014, 9:52:34 AM1/20/14
to puppet...@googlegroups.com
Hi,
as far as I understand, spacing should usually not be an issue in manifests between the attribute name and the "arrow", right?

For example, for a "host" type resource:

  ip => "192.168.1.1"

…should be the same as:

  ip       => "192.168.1.1"

Is that right?
It's useful to make manifests easily readable, and I see it used in examples, too.

But I encountered a problem with the "ip" attribute of the "host" resource: if I add more spaces after "ip", just like the example above, I get an error telling me that the "ip" attribute is required, as if it was absent.
Without extra spaces, instead, it works.

Is this a bug which needs to be reported?

Thanks.
Marco

jcbollinger

unread,
Jan 21, 2014, 10:05:48 AM1/21/14
to puppet...@googlegroups.com


On Monday, January 20, 2014 8:52:34 AM UTC-6, zerozer...@gmail.com wrote:
Hi,
as far as I understand, spacing should usually not be an issue in manifests between the attribute name and the "arrow", right?



Right.

 
For example, for a "host" type resource:

  ip => "192.168.1.1"

…should be the same as:

  ip       => "192.168.1.1"

Is that right?


That is right.

 
It's useful to make manifests easily readable, and I see it used in examples, too.

But I encountered a problem with the "ip" attribute of the "host" resource: if I add more spaces after "ip", just like the example above, I get an error telling me that the "ip" attribute is required, as if it was absent.
Without extra spaces, instead, it works.

Is this a bug which needs to be reported?



If it were indeed the case that adding space characters (U+0020), tab characters (U+0009), newlines (U+000A), and / or line feeds (U+000D) between the parameter name and the arrow broke a resource declaration, then that would be a bug that should be reported.  I find that highly unlikely, however.

Possible alternative explanations:
  • You are quoting the parameter name (which is fine), and at least some of the added whitespace is going inside the quotes.  "ip " => "192.168.1.1"
  • You are inserting at least one character different from those enumerated above between the parameter name and comma.  There are several that are normally rendered as a span of empty space, and there are many others that normally are not rendered at all.  None of those is considered whitespace for the DSL's purposes, but depending on where exactly they appear, they might be syntactically valid.  Perhaps you changed the "ip" parameter to "ip<some non-printing character>"

John

zerozer...@gmail.com

unread,
Jan 22, 2014, 6:32:54 AM1/22/14
to puppet...@googlegroups.com
On Tuesday, January 21, 2014 4:05:48 PM UTC+1, jcbollinger wrote:
 
Possible alternative explanations:
  • You are quoting the parameter name (which is fine), and at least some of the added whitespace is going inside the quotes.  "ip " => "192.168.1.1"
  • You are inserting at least one character different from those enumerated above between the parameter name and comma.  There are several that are normally rendered as a span of empty space, and there are many others that normally are not rendered at all.  None of those is considered whitespace for the DSL's purposes, but depending on where exactly they appear, they might be syntactically valid.  Perhaps you changed the "ip" parameter to "ip<some non-printing character>"
Well, I did not quote the attribute name, so maybe I was in the second case you suggested.
I can't imagine how any different char might have ended up in there, but following your reply and also having found again in the docs that whitespace is not relevant I did a new test now, and puppet did not have any problems with added spaces after the attribute name.
So, who knows what happened. I'm also pretty sure I already tried adding the spaces back yesterday as a test, and it failed. But you never know.

Thank you, sorry for bothering.

Marco
Reply all
Reply to author
Forward
0 new messages