I'm looking for a way to get the platform end of line character sequence (CRLF for Windows, LF for Linux/macOS) at runtime.
1 Answers
I don't believe there is any feature that does this specifically. Even the line-aware features of the standard library don't: BufRead::read_line
is documented to only recognize \n
, and BufRead::lines
(source), which strips end-of-line characters, only does so for \n
and \r\n
, indiscriminate of what platform it's invoked on.
"Platform line ending" is really a category error, though. Files are sent across networks and copied from one computer to another. If your program writes files that need to be opened on Windows in Notepad, it doesn't matter whether the program that generates them is running on Windows or Linux; it needs to emit \r\n
. Similarly if the program is writing a specific file format or implementing some network protocol; the format or protocol should tell you what line separator to use. If the format allows either and there is no convention, pick the one you prefer; just use it consistently.
If you're reading line endings, you should probably tolerate either one, like BufRead::lines
does.
However, should you really need to, like if your output will be read by a poorly written program that expects different line endings on different platforms, you can use conditional compilation attributes to achieve this effect:
#[cfg(windows)]
const LINE_ENDING: &'static str = "\r\n";
#[cfg(not(windows))]
const LINE_ENDING: &'static str = "\n";
-
10Nice answer, except for one nit: there *is* such a thing as a native line ending for the platform, and a program that creates local text files that need to be viewed and edited should respect it. At least I know I hate programs that create files with CRLF endings on Unix. – user4815162342 Nov 29 '17 at 12:58
-
3@user4815162342 You make a good point, although I'd argue that programs that create local text files for human viewing should unconditionally use `\n` and users should just use, oh, *any program other than Notepad* to view them on Windows. – trent Nov 29 '17 at 13:13
-
1I understand where you're coming from :) but unconditionally using `\n` does seem a bit Unix-centric. There are situations where the OP's question makes perfect sense, although I concede that they are much rarer than they're made out to be. – user4815162342 Nov 29 '17 at 18:27
-
Thanks I was gathering info to solve a bug in cobalt : https://github.com/cobalt-org/cobalt.rs/issues/241 – Geob-o-matic Nov 29 '17 at 18:33
-
2Note: even MS Notepad supports \n now: https://devblogs.microsoft.com/commandline/extended-eol-in-notepad/ – Denys Séguret Sep 06 '19 at 13:48
-
2This should just be defined in std somewhere like path separater is. It's inconsistent and annoying not to have the native line ending available where needed. E.g. https://doc.rust-lang.org/std/path/constant.MAIN_SEPARATOR.html – Squirrel Dec 03 '20 at 12:55
-
The useful thing to do would be to be able to write out a file given the line endings that it was read in with. Given the problem domain you may also want to be able to configure writing dos or unix line endings on either kind of system based on the user specifying how they're going to eventually wind up being consumed (managing dos-line-endings on a linux machine and vice versa was a use case I had to support at $priorjob). – lamont Apr 03 '23 at 01:26