I meant Zack :)

On 27 June 2013 00:48, Ignasi Barrera <notifications@github.com> wrote:
>> @@ -129,14 +129,14 @@ public void testOneRecipe() throws IOException {
>>        replay(validatorKey);
>>
>>        assertEquals(
>> -            fn.apply("foo").render(OsFamily.UNIX),
>> +            fn.apply("foo").render(OsFamily.UNIX).replace("\r\n", "\n"),
>
> Great investigations Zach! As you say, Pems.java seems to be the bad boy here: https://github.com/jclouds/jclouds/blob/master/core/src/main/java/org/jclouds/crypto/Pems.java#L403
>
> I don't think it is a bug in Pems.java, because it will generate the PEM file with the line terminations according to the OS where it is being run.
>
> The bug is in Chef: basically in chef we are composing a script that will be uploaded to the node, and in the `render` method we tell the scriptbuilder in which target OS the script be executed, so it can be properly generated. The problem is that if we are generating the script in a Windows machine, we are passing a string literal (the private key in PEM format) with CRLF characters to be directly appended to a file, and the scriptbuilder does not manipulate the string provided by the user.
>
> I think the correct approach here would be to slightly modify [these lines](https://github.com/jclouds/jclouds-chef/blob/master/core/src/main/java/org/jclouds/chef/functions/GroupToBootScript.java?source=cc#L110-111) so they return an statement that overrides the render method to do the replacement of the line terminations when rendering to UNIX (rendering to Windows is still not supported in chef). That statement could be a decorator of the current `appendFile` that replaces the line terminations after the delegate statement renders the script fragment. This should also allow us to leave the tests unchanged.
>
> WDYT?
>
>
>
> ---
> Reply to this email directly or view it on GitHub:
> https://github.com/jclouds/jclouds-chef/pull/5/files#r4905205