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;
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?
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")
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…