2

Which line endings should be used for platform independent code (not file access)?

My next project must run on both Windows and Linux.

I wrote code on Linux and used Hg to clone to Windows and it ran fine with Linux endings. The downside is that if you open the file in something other than a smart editor the line endings are not correct.

Kenny
  • 675
  • 10
  • 24
  • @pp_ This question is about which line ending to use in the actual code not file access. – Kenny Feb 25 '16 at 22:25
  • It's still a duplicate. – pp_ Feb 25 '16 at 22:29
  • 1
    @pp_ Please provide a reference. I'm happy to read it. Searching to find an answer to this was difficult because most are asking about file I/O. – Kenny Feb 25 '16 at 23:22
  • https://stackoverflow.com/questions/1552749/difference-between-cr-lf-lf-and-cr-line-break-types – pp_ Feb 25 '16 at 23:27
  • A some more [here](https://stackoverflow.com/questions/1279779/what-is-the-difference-between-r-and-n) and [here](https://stackoverflow.com/questions/8893132/writing-new-line-character-in-java-that-works-across-different-os) (somewhat related) – pp_ Feb 25 '16 at 23:33
  • I also found [this](https://stackoverflow.com/questions/3821784/whats-the-difference-between-n-and-r-n). And [this wikipedia article](https://en.wikipedia.org/wiki/Newline) is great, too. – pp_ Feb 25 '16 at 23:37
  • Possible duplicate of [What type of line breaks does a Python script normally have?](http://stackoverflow.com/questions/6907245/what-type-of-line-breaks-does-a-python-script-normally-have) – Mogsdad Feb 26 '16 at 22:52
  • @pp_ This is not what I am asking. – Kenny Feb 26 '16 at 22:58
  • @Mogsdad Yes. A duplicate of this question. Not a very satisfying answer but I think I can opt to just use Linux line endings and good editor (which I have). Just need to convince the team to do the same. – Kenny Feb 27 '16 at 00:40
  • On our team, we have devs on multiple OSes and editors. We use post-commit triggers in our VCS to enforce consistent line endings (Unix), and devs have their clients check files out according to their preferences. – Mogsdad Feb 27 '16 at 00:47
  • 1
    @pp_ it's interesting to see the questions you nominate as duplicates of this one. I understand that SO moderators want to keep the content clean but I think there must be some financial reward offered for closing questions. I often come across really good questions with really good answers that have been closed and there's a host of objections. Those questions you nominate are in no way shape or form duplicates of this one. I think moderators need to be a lot more restrained in nominating closures and should at least make sure they understand the questions they're reading first. – NeilG Dec 01 '22 at 23:04

2 Answers2

1

In general newlines (as typically used in Linux) are more portable than carriage return and then newline (as used in Windows). Note also that if you store your code on GitHub or another Git repository, it will convert it properly without you having to do anything.

John Messenger
  • 351
  • 1
  • 8
0

As John Messenger states, newlines (\n) as opposed to carriage-return/linefeeds (\n\r) are pretty much the canonical line ending everywhere, except for dedicated Windows-only enclaves.

To support this, git has the core.autocrlf option. When enabled on Windows systems, files with standard newline endings will be converted to CRLF when checked out, and converted back on the way back in.

This seems to be a seamless way to cope with the problem of Windows line-endings when running GUI editors and IDEs on Windows. Your editor is probably expecting CRLF line endings on Windows and will get them when using git with this option, which I believe is set to true by default on Windows installs.

If you're not using Git, maybe it's time you did? Even when working alone it has lots of value.

However, some users will be using GitBash / Cygwin / Ming tools on Windows, possibly with GitBash supplied vim, and will not appreciate CRLF line-endings. Those users can turn core.autocrlf off (false) before cloning a repo to avoid inappropriate "corrections", and thereby see proper newline-only line endings when editing files. This may also help when using other Linux tools when running on Windows that also expect newline line endings.

Git has three levels of settings: "system" (probably set in C:\Program Files\...), "global" (set in your home directory Git config file and affecting all your repos) and "local" set in each repo's .git/config file. Latter levels override the former levels, which can be helpful if your organisation has locked down your C drive.

Here are some of the Git commands to query and update your settings (and you can just edit the configuration files themselves as well):

  • git config --list --show-origin: Lists all your settings and the file locations where they are set. A setting may be repeated so the lower level will override the higher.
  • git config --get core.autocrlf: Get the effective setting from the combination of settings you currently have in place.
  • git config --system core.autocrlf false: Switch off automatic conversion at the system level, for all repos.
  • git config --global core.autocrlf false: Switch off automatic conversion in all repos from your home directory config file.

Remember, set core.autocrlf to what you need before you clone. Reference here: https://docs.github.com/en/get-started/getting-started-with-git/configuring-git-to-handle-line-endings

NeilG
  • 3,886
  • 2
  • 22
  • 30