The line-break marker on Windows should be CR+LF
whereas on Unix, it\'s just LF
.
So when I use something like Console.Write(\"line1\\
In my experience, when you output to the Console with WriteLine() it accepts the \n escape character. When you are using a StreamWriter and call WriteLine() it makes you type \r\n to move to a new line. I assume that the Console has been programmed to accept the \n escape character without the carriage return \r.
\n is the line feed character. On both *nix and Windows systems it should create 2 lines. The \r is the carriage return, it moves the writing instrument to the beginning of the line.
Most modern consoles/editors are resilient enough to interpret \n as \r\n
'\n'
is the Line Feed character. Traditionally, it caused the printer to roll the paper up one line. '\r'
is the Carriage Return character, which traditionally caused the printer head to move to the far left edge of the paper.
On printers and consoles that interpret the characters in this manner, the output of line1\nline2
would be
line1
line2
Many consoles (and editors) will interpret '\n' to mean that you want to start a new line and position the cursor at the beginning of that new line. That is what you see here.
You should use Environment.NewLine rather than hard-coding any particular constants.
File encodings != Console
interpretation.
In other words, while the "Windows Standard" of CR
+ LF
exists for files, just the LF
, or \n
has resulted in the appropriate carriage return and new line interpretation in console windows.
This is just the standard behaviour of the underlying Windows console. A native C app will do exactly the same if you output 0x0A
to the console.
Of course, you should be using Environment.NewLine for your new lines. Environment.NewLine
resolves to \r\n
on Windows and \n
on Unix like systems.