spent some of a lazy Sunday arvo improving the Lucee test coverage, managed to find one obscure bug https://github.com/lucee/Lucee/pull/1909

Enhancing the test coverage is always appreciated, thanks. About fileWriteLine: It might be debatable that this is a bug. Are you sure that it is? (It seems to behave as I would have expected.) Maybe there's precedent elsewhere in Lucee for implicit producing artifacts with different line endings per environment (in which case may be a bug, if only of consistency) but Lucee aside, there's general debate about whether or not to dogmatically use crlf on windows (since, generally speaking, windows editors support lf). Even notepad, the last holdout (afaik) finally supports them, as of 2018.

end of the day, comes down to what ACF does on windows

Well: it's the std windows EOL marker, innit? Since... well... forever. This isn't CF's fault. Shouldn't Lucee have been using

System.lineSeparator()

all along?

that's my opinion, but aren't you do Mr Lucee should just do what ACF does ColdFusion Server 2021,0,05,330109 uses the correct line endings

[97,13,10,98,13,10,99,13]

Sorry, yes I am. I misinterpreted what you meant by "end of the day, comes down to what ACF does on windows" to suggest CF was somehow doing something wrong by using CRLF. @jamiejackson I think there's a difference between "supports" and "is the file system default". Lucee can support writing LF as a EOL marker if one chooses to use one. That would be the analogy to notepad having it as an option, etc. (How do you specify which to use on notepad, out of interest? I cannae see it)

Yup, my OP was wrong.

System.lineSeparator()

makes sense. @Adam Cameron, not sure how to author a LF doc but the read support is mentioned here: https://devblogs.microsoft.com/commandline/extended-eol-in-notepad/

Cool. Just tested. Yeah opens a file with LF endings just fine (and renders fine). If I add more lines, it adds them with LFs too.