[chef] Re: RE: Re: Re: Re: RE: Re: RE: RE: Newlines in templates


Chronological Thread 
  • From: Tensibai < >
  • To: < >
  • Subject: [chef] Re: RE: Re: Re: Re: RE: Re: RE: RE: Newlines in templates
  • Date: Thu, 07 Nov 2013 16:12:03 +0100

I really don't agree saying the node is in the best position, it may depend on the purpose of the file rendered.

So yes, it could be of some help in limited cases to have an attribut like line_ending: (cr|cr-lf|lf|target-ending) into the template ressource. 

Indeed, you should not have to convert a community cookbook (but when needed, dos2unix/unix2dos or (to|fro)dos under ubuntu are great help for that). 

The files and template sources dir in a cookbook can be specified toward the target os, the most precise wins, so files within a windows dir should have cr-lf endings and files under a redhat or ubuntu or linux dir should have a lf ending (I won't go about OS X as I don't manage this kind of systems).

A file within the default dir is generally os agnostic and depends more on the way the app read the file than the node os on which the app run.

In brief: I think it could be an attribute into template, but it sounds like a real overhead, maybe a hwrp extending the template ressource which can be included or not would fit better, but I may be wrong in this assumption ?

 

Maybe the debate worth a ticket on chef jira.

 

Le 2013-11-07 15:27, THARP, JOSHUA L a écrit :

I’m with Daniel. The node that downloads the files from the Chef server is in the best position to know the required end of line character. Julian’s point supports mine nicely. How can I tell Git or my editor to always use <LF> or <CR><LF> when some cookbooks (and therefore templates) might be used on more than one platform? Perhaps Opscode could add a tag to templates that flags chef-client to make the file’s end of line characters conform?

 

@Tensibai I too use gvim and can control the line endings. However, what set this off was the use of a community cookbook. I could edit the community cookbook to change the line endings, but I shouldn’t have to.

 

From: Tensibai [mailto:
Sent: Thursday, November 07, 2013 1:16 AM
To:
Subject: [chef] Re: Re: Re: RE: Re: RE: RE: Newlines in templates

 

 

FWIW:

I think the file format and encoding is the responsability of the cookbook/template writer.

There's plenty of editors allowing to set the file encoding and line endings the way you wish.

I think about gvim and notepad++ for thoose I actually use for this purpose.

At least it must be an option as magically converting a file at rendering could become confusing.

I think about rendering config files on a server to push them toward a switch later, you may wish to keep the encoding of the file even if it is not the server base encoding.

 

Tensibai

 

Le 2013-11-07 04:40, Daniel Condomitti a écrit :

Could it be done at the time that the template is actually parsed and written to disk based on the platform type?

 

On Wednesday, November 6, 2013 at 7:02 PM, Julian C. Dunn wrote:

On Wed, Nov 6, 2013 at 9:03 AM, THARP, JOSHUA L < "> > wrote:

I am using Git, and with a little work (and a global setting that affects

all repositories) I can have it change the newlines. However, the question

remains if it is possible for Chef to do newline conversions. If I’m editing

on a Windows PC, and I upload my cookbook – targeting a *nix platform – the

cookbook is going to have the wrong line endings, and many Linux

configuration files as well as shell interpreters are sensitive to the line

endings. I would think mine is a fairly common scenario.

 

Joshua,

 

While that's true, there's no sensible default that Chef could take.

What if you're managing a mixed Linux/Windows infrastructure with

Chef, and some of the templates need Windows-format line-endings and

others need Unix-format ones?

 

- Julian

 

--

[ WWW: http://www.aquezada.com/staff/julian * only Web 1.0 ]

[ gopher://sdf.org/1/users/keymaker/ * compliant! ]

[ PGP: 91B3 7A9D 683C 7C16 715F 442C 6065 D533 FDC2 05B9 ]

 

 

 

 

 



Archive powered by MHonArc 2.6.16.

§