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\nline2");, why would it work "properly" and give me two lines? I expect this \n not to work, and only a combo of \r\n would work.
Console.Write() - user1032613 2012-04-05 19:15
Chr(13) alone did not give me a new line. I had to use MsgBox("ln1" + Chr(13) + Chr(10) + "ln2"). - user1032613 2012-04-05 19:18
'\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.
type myFileWithSlashNDelimiters will display the text, either as separate lines or one long line. Not sure which, but either way it's a viewer. I answered before his clarifying comment that he is using Console.Write() - Eric J. 2012-04-05 19:35
\n is the Line Feed character in the ASCII table, so of course, you get a new line. The unexpected thing is that the Console.Write method seems to also imply \r, which the asker is not supplying, and which is the Carriage Return - H2ONaCl 2014-06-29 10:44
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.
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.
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