Practical difference between \n and \r\n

[Sun Tiantang]

Sorry if this might sound silly. I was reading some blog about string yesterday and this got my attention. It seems that \n and \r\n differ mainly in different OS and it is said that on Windows Environment.NewLine should be used.

But still I can't see any difference between the following two fro the console window:

Console.WriteLine("Test\nThis is a new line");

Console.WriteLine("Test\r\nThis is a new line");

Can someone share some insight on what's practical difference between those two in other cases please?

Thanks.

Tiantang

 

[Anders Eriksson]

But still I can't see any difference between the following two fro the console window:

Console.WriteLine("Test\nThis is a new line");

Console.WriteLine("Test\r\nThis is a new line");

Can someone share some insight on what's practical difference between those two in other cases please?

The difference is that \n will write a LF and \r\n will write LFCR

BUT the console will treat LF as a new line so in the console you will
not see any difference.

If you run this program and look at the redirect.txt file in an editor
that can show "special" characters (e.g. Notepad++) you will see the
difference I have described.

// Anders

static void Main(string[] args)
{

FileStream ostrm;
StreamWriter writer;
TextWriter oldOut = Console.Out;
try
{
ostrm = new FileStream("./Redirect.txt", FileMode.OpenOrCreate,
FileAccess.Write);
writer = new StreamWriter(ostrm);
}
catch (Exception e)
{
Console.WriteLine("Cannot open Redirect.txt for writing");
Console.WriteLine(e.Message);
return;
}
Console.SetOut(writer);

Console.WriteLine("Test\nThis is a new line");

Console.WriteLine("Test\r\nThis is a new line");

Console.SetOut(oldOut);
writer.Close();
ostrm.Close();

Console.WriteLine("Test\nThis is a new line");

Console.WriteLine("Test\r\nThis is a new line");
#if DEBUG
Console.ReadLine();
#endif

}

 

[Anders Eriksson]

The difference is that \n will write a LF and \r\n will write LFCR

Oops! I shouLd of cause be CRLF.

// Anders

 

[Sun Tiantang]

Oops! I shouLd of cause be CRLF.



// Anders

--

English isn't my first language.

So any error or strangeness is due to the translation.

Please correct my English so that I may become better.

Thanks for making this clearer!
Interestingly TextPad treats \n the same as \r\n whereas notepad doesn't not.

 

[Registered User]

Thanks for making this clearer!
Interestingly TextPad treats \n the same as \r\n whereas notepad doesn't not.

A little history .... Back when all there was were mainframe computers, printers
used one command for a carriage return and another for a line feed. Using both
commands was important to avoid damaging the printer's platen (roller). If line
feeds weren't used the platen wouldn't advance and the damage would be caused by
continuously printing over the same location on the platen.

The Console.Write method exhibits the same behavior when a carriage return is
used.

Console.Write("1\r");
Console.WriteLine("2");
Console.WriteLine(" - done -");
Console.ReadKey();

The output from the snippet above is:
2
- done -

regards
A.G.

 

[Arne Vajhøj]

Sorry if this might sound silly. I was reading some blog about string
yesterday and this got my attention. It seems that \n and \r\n differ
mainly in different OS and it is said that on Windows
Environment.NewLine should be used.

But still I can't see any difference between the following two fro
the console window:

Console.WriteLine("Test\nThis is a new line");

Console.WriteLine("Test\r\nThis is a new line");

Can someone share some insight on what's practical difference between
those two in other cases please?

\n is one character and \r\n is two characters.

Different environments has different conventions for new line.

*nix (Unix, Linux, MacOS X etc.) disk files use \n for new line.

Windows (and DOS) disk files use \r\n for new line.

Old MacOS (pre X) disk files uses \r for new line.

Real VT terminals use \r\n for new line.

Most network protocols use \r\n for new line.

Many products on Windows recognize \n as new line in disk files.

On *nix application outputting \n to terminal will result in \r\n being
sent to terminal.

Environment.NewLine is \r\n on Windows and \n on *nix (Mono).

So what to use?

here is my recommendation.

For disk files use either WriteLine or Environment.NewLine
as that will properly handle the difference between Windows and *nix.

For console use one of WriteLine or Environment.NewLine (\r\n
will always work also, but to be consistent with WriteLine then
I recommend Environment.NewLine).

For network use \r\n (WriteLine or Environment.NewLine is the
same on Windows, but on *nix they may be a protocol violation).

Arne

 

[rbowman]

Can someone share some insight on what's practical difference between
those two in other cases please?

Somewhat obscure, but our codebase was developed on AIX and the GUIs were
created using the Motif toolkit which runs under the X Window system. As our
clients migrated to Windows we ported the code using a third party toolkit
but the GUIs still are Motif using a Windows X server.

AIX uses \n alone. If a text file edited on Windows is read in and displayed
in most Motif widgets, the \r will not be handled correctly and will appear
as a little CR character.

Other gotchas. When ftping binary files using a Windows client unless you
specify the binary mode, which usually is not the default, the Windows ftp
client will 'help' you by inserting the \r before any \n it finds. Needless
to say, the binary executable is trashed in the process.

I haven't hit the problem in C#, but in straight C using stat() to determine
a file's size may not be the same as the number of bytes read when reading
in the entire file depending on \r\n is handled.

Some protocols are also unforgiving. For example the SMTP protocol requires
\r\n as a terminator.

Unless you're doing cross platform work, \r\n is the safest.

 

[Arne Vajhøj]

Somewhat obscure, but our codebase was developed on AIX and the GUIs were
created using the Motif toolkit which runs under the X Window system. As our
clients migrated to Windows we ported the code using a third party toolkit
but the GUIs still are Motif using a Windows X server.

AIX uses \n alone. If a text file edited on Windows is read in and displayed
in most Motif widgets, the \r will not be handled correctly and will appear
as a little CR character.

Well known problem. There are utilities to convert text files.

Other gotchas. When ftping binary files using a Windows client unless you
specify the binary mode, which usually is not the default, the Windows ftp
client will 'help' you by inserting the \r before any \n it finds. Needless
to say, the binary executable is trashed in the process.

No surprise. Binary/image and text/ascii actually mean something.

I haven't hit the problem in C#, but in straight C using stat() to determine
a file's size may not be the same as the number of bytes read when reading
in the entire file depending on \r\n is handled.

Besides different line separators there are also file systems where
lines are not separated by a separator but instead are counted.

Examples:
<2 bytes with length> + line + <0 or 1 null byte to pad to even>
<6 bytes with length> + line + <6 bytes with length>

It is not safe to assume that the file size and the sum of the
length of lines are identical.

Arne

 

[rbowman]

Well known problem. There are utilities to convert text files.

Yeah, we distribute dos2unix with our maintenance tools. Most of our support
people are younger and have only used Windows. I get a migraine when they
open a configuration file in Notepad. Notepad has a nifty feature. If you
add a line at the end of the file without hitting <Enter> and save the file
Notepad dutifully saves the last line with no \r or \n at all.

All these quirks shouldn't be a problem, but a lot of code is old enough to
retire and we made some rash assumptions back in the day -- like time_t. I
lived through Y2K and I'll be lucky to be alive let alone working for 2038.