ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
Technically, they aren't the same, though. CR returns the cursor to the beginning of the line, and LF moves the cursor down a line, (but doesn't necessarily return it to the beginning of the line.) In Windows, though, when writing a \n it is typically translated underneath to \r\n when writing to text-mode files.
Why they thought they needed TWO characters for the same thing that is accomplished by one in every other operating system is beyond me.
This is wrong, many of the non Unix/Unix like O/Ses use CR-LF, and not exactly the problem.
Every terminal or terminal emulator need both CR and LF to go to the next line, including GNU/Linux and Unix.
Before Unix and C were invented, that convention was used too for representing an end of line in text files on all operating systems using ASCII. That was easing the display of a file on a screen (or a teletype) as no processing was required to "cat" a file.
C created the "\n" convention (newline) to represent the end of lines in text files, regardless of the underlying O/S (of course at the beginning the only C underlying O/S was Unix).
That was saving a little storage space, and easing all programs dealing with files (a single character is faster to locate that two) and improve response time of interactive programs at a time when sending one byte could cost a noticeable amount of time ...
However that added some complexity to the terminal drivers, which had (and still have) to convert this delimitor in what the terminal expects/sends.
See the numerous stty options to deal with that mess: inlcr igncr icrnl onlcr ocrnl onocr onlret echonl