Can I change my linux system EOL to use \r\n instead of \n by configuration files?

Question

I want to change the default EOL of my linux system from \n to \r\n without recompiling it. Any configuration makes this possible (maybe locale)?

Reason: I must make sure that for every user that creates a file, the file will be correctly formatted (without forcing him to use unix2dos or something else)

Answer 1

I'm editing my answer to provide this summary on top. I believe the direct answer to your base question is "No, this is not an option that is commonly supported on many Linux systems". Following is my more detailed explanation.

I doubt that this can be easily done. In theory, multiple operating systems use different newline characters, as noted by Wikipedia: Representations. In theory, programmers should not refer to \n or \r\n when they want to represent a “newline character” (which might be a character, like the Record Separator character of old QNX systems, or \r\n, like MS-DOS). That way, if anyone (soon, or down the road) wishes to re-use the code, they could simply change one variable.

In practice, many programmers have been known to “hard code” values. You could use “Linux from Scratch”, and customize the system however you like. I suppose that if you modified the source code, you could make it so that all your system's configuration files used whichever newline sequence you prefer.

However, what happens later when a user wishes to use a specific text editor, or a specific web browser? Are you prepared to go “fix” your own variation of the Google Chromium web browser's source code, just to accommodate this change?

As you can see from ChrisEdmonton's comment, implementing this change would actually be unusual. This means that you're likely to find lots of things don't work well with one person's goal of implementing such flexibility. So you're likely to encounter quite a few problems. I speculate you're likely to encounter quite a few problems down the road, well after things seem to be initially okay.

Personally, my computer data has some value to me. Even data that is so worthless that I don't bother to back it up, has enough value to me that I don't want to intentionally do something that is likely to cause problems. (Just because I'm willing to allow the data to be lost in the unlikely event of a catastrophe, doesn't mean that I want to metaphorically dump gasoline all over the floor on one side of the house, uselessly intentionally causing a situation that may be likely to cause a catastrophe.)

So unless you're willing to look at all sorts of things, including filesystem drivers and kernel code that handles memory, and all other aspects of the system, then this probably is not worth pursuing. I suggest using another way to implement the change.

Yes, I know the argument that Linux is supposed to be open source, so it should be customizable. But the reality is that Linux has grown so much that making a change can have significant consequences. Keep in mind that there are different versions of Linux (Debian, Ubuntu, Mint, Red Hat, SUSE, etc.), not to mention other Unix-like operating systems (BSD, Solaris, Mac OS X) and other operating systems (Windows, DOS, CPM, VMS). In theory, making a change like this ought to be easier than trying to convince Microsoft to make a change to their closed-source operating system. In practice, there may be a lot of people that you would need to convince in order to make a change to some of the more popular software out there. Making changes can break stuff, and so changes ought to be made when there is significant, substantial benefit. More frivolous changes are unlikely to be worthy of the difficulty that they may implement.

Some people might like to have such changes to be an easily-modifiable option. One problem with lots of options is that having too many options can clutter up user interfaces, and can clutter up documentation, and can complicate source code (even if the added complexity is fairly small), so there are people who promote the idea of creating standards and reducing options, for the sake of simplicity. Therefore, a change like "customize newline character for software which supports this option" may introduce more pain than the expected benefit for such an option.

Your provided reason is to not want the user to use "unix2dos" when creating a file. How does the user create a file? Does the user run "nano"? You could potentially replace "nano" with a script, which runs the normal nano, and then runs unix2dos automatically. You could modify the process that users create/edit files, or you could modify the process that affects how the file gets transferred to other machines that might expect \r\n (and then not care if the file is using only \n while the file is still on the Linux machine). Such targeted approaches are far more likely to work will, without unintended consequences, rather than trying to make a system-wide change that affects how the entire system works.