Reading \r (carriage return) vs \n (newline) from console with getc? Reading \r (carriage return) vs \n (newline) from console with getc? c c

Reading \r (carriage return) vs \n (newline) from console with getc?


\n is the newline character, while \r is the carriage return. They differ in what uses them. Windows uses \r\n to signify the enter key was pressed, while Linux and Unix use \n to signify that the enter key was pressed.

Thus, I'd always use \n because it's used by all; and if (x == '\n') is the proper way to test character equality.


The '\n' is the "Line Feed" and '\r' is the carriage return. Different operating systems will handle new lines in a different way, such as

Windows

Expects a newline to be combination of two characters, '\r\n'.

Linux\Unix and Modern Mac OS

Uses a single '\n' for a new line.

Classic Mac OS

Uses a single '\r' for a new line.

Basically, I would use if (x == '\n') as it is currently used by all modern operating systems.


There are several levels of abstractions of representing a new line - the programming language runtime, the text editor and the OS. CR (carriage return) and LF (line feed) are two control charactors that are defined in ASCII. Some other charator encoding might also define a "new line" charactor. The Enter key on any keyboard conveys a meaning of "to the beginning of the next line". The keyboard decides how to map the Enter key to its corresponding control charactor or charactors. Some keyboard also differentiates Enter and Return key - let Enter key be new line and Return key be carriage return. In a standard ANSI keyboard, there's only Enter key, which is mapped to a carriage return charactor (13) in ASCII. So this is the actual content that is sent to the OS by the device. However, different OS decides to interpret the Enter key differently. So in Unix-like system, any carriage return is translated to a line feed charator (10 in ASCII) before handing to the program that receives the input. And on Windows, a CR is translated to two charactors - a CR followed by a LF. However, you can set the input stream to be raw mode, in which case the program gets what the keyboard actually sends. Now the editor comes into play. When the editor receives a CR from stdin in raw mode, it knows the CR corresponds to the Enter key on the keyboard (assumption about the keyboard) and it's supposed to display a new line on the screen. In the raw mode, it should call the write system call to output a CR + LF. If the output stream is not in the raw mode, the text editor should output the OS-specific sequence such as LF on linux.

Finally, the language runtime can also interpret the new line in its own way. For example, The C standard says When writing a file in text mode, '\n' is transparently translated to the native newline sequence used by the system, which may be longer than one character. When reading in text mode, the native newline sequence is translated back to '\n'. In binary mode, no translation is performed, and the internal representation produced by '\n' is output directly. Note that '\n' and '\r' are language-specific charactors that represent LF and CR respectively that are popular in C-like languages. But not every language has to use this notation.

For you second question, "\n" is '\n' followed by a '\0' terminator. There is no way to enter a '\0' from the console.