newLine() Function

dev support
1

I have the following code that runs on a Linux server

<cfset csvResults = createObject("java", "java.lang.StringBuffer") />
<cfset newLine = Chr(13) & Chr(10) />

I then use the newLine variable at the end of the dynamically produced line.

One of our customer states, that they cannot process the file, automatically, however.
They must open the file in excel, then save it (still as a CSV not a native excel document) - and then it works.

I was told they have determined that the line-endings are the issue…
I don’t understand why the CR+LF is not working correctly.
NotePad ++ shows the line endings as being CF LF - but is that because that is what is IN the file or simply because I am viewing the filew on a windows machine?

Nonetheless, I thought I might change from the Chr(13) & Chr(10) - to using the newLine() function as a point of difference.

(I have no reason to believe it will work - over what I am doing - but…)

The newLine function has the following argument;

includeCROnWindows

and the Lucee docs has this to say about it;

boolean, optional
On windows computer include Carriage Return.

Which isn’t really helpful.
Does it mean that if I am using newLine() in the creation of a CSV file - and my Lucee server is on a windows machine - that my CSV will contain CR+LF?
But if my Lucee server is a Linux-based system - it will create a CSV using LF only?

Or does it mean something entirely else?

2

What a weird setting. Why would the app server OS ever be relevant to whether or not to include the CR?

3

I don’t have a dog in this fight, but I’ll share some thoughts if they may help (or save time for others looking this up /writing it):

  • cf doesn’t have this function, so I’d not considered it to now
  • as for why lucee has this arg to work differently, that’s discussed in this jira ticket from 2018 when the arg was added: LDEV-1957
  • as some here know (including the thread participants, I’m sure), it’s indeed a longstanding point of contention between Linux and Windows about cr, lf, and cr/lf. A very helpful article on that was offered in recent weeks here
  • as for that newline function that lucee (railo?) added, note that in the jira ticket about this new arg it was discussed in contrast to the then-available Server scope variable offered by lucee (not cf), server.separator.line
  • while i haven’t dug into the lucee source, I suspect that that var was based on the available Java system property line.separator, where Java in fact handles changing the value based on the OS (see above). It seems somehow that this intelligence wasn’t embued in the function.
  • finally, if one wanted to access that system property (such as to use it in ACF, or just to view it), it can of course be accessed in cfml such as via CreateObject("java", "java.lang.System").getProperty("line.separator")

Hope that’s helpful.

2 Likes
4

My cross-platform solution years ago was (to me) surprisingly simple:

<cfscript>
strCR = "
";
</cfscript>

Sometimes I like to think that I am clever.

:slightly_smiling_face:

I have no idea whether that’s relevant to the dynamic generation of a .csv file, but worth a try?

5

I will give it a go - thanks!

6

A little more digging…

The process runs on a linux server.
I attach the csv file I create via cfmail and email it to myself,
If I open the file attached in my email - on my windows machine - in NotePad++ - I get the CF+LF.

The file that is on the linux server, separately to the email - additionally gets SFTPd.
The SFTP processis done via BASH.
I cannot use Lucee’s built-in FTP funcitons - the algorithm for the certifacate used for autentication is ED25519 - and this is not supported by Lucee.

If I download the file from the FTP server onto my Windows machine and open it with NotePad++ - it does indeed ONLY have the CR line ending - despite the CR+LF line ending I am programatically adding…

When I swapped to using the newLine() function - instead of the CR+LF addition… it actually created a file that had no line endings at all.

I am not sure how this helps at all - but perhaps the extra information highlights something in the dark shadows…

As always
Thanks for any help you might imagine!

7

Another quick update…
I have changed it to appending
"
"

literally an new line…
But it has produced another single line file.
:frowning:

oh and just as a follow-up…
I also just tried Chr(13) & Chr(10) & Chr(10)

Becaue if you’re file is missing a LF… you add one in, right?
Unfortunately - when I open the file that we place omn the SFTP server - it still ONLY has a CR and no LF.

8

It is fairly common for FTP clients to be “helpful” and translate line endings in text files for you. You might look at those settings for your ftp client and server. A random google result below.

1 Like
9

Thanks @Dan_MacNeil
That will solve my “But it is working on my dev machine…” claim.

10

I have solved the issue for myself - but not by correcting anything in Lucee.
It will need more research.

I solved it by running “sed” and replacing the CR with a CR+LF, in the bash file - that I have to use to perform the SFTP transfer.

Gavin.