Zytan wrote: [...]
It replace \n with \r\n without replacing \r\n with \r\r\n.
Well, \r\r\n wouldn't be proper, anyway, right, so it doesn't really
matter if you fix it or not, since it's already broken?
Your code ensures that only 0 or 1 \r is pre-fixed before \n, before
being replaced with Environment.NewLine, which is always the proper
carraige return for the system running the code. Right?
No. As he said, it replaces \n with \r\n without replacing \r\n with
\r\r\n. In ensures that exactly 0 \r is pre-fixed before \n before being
replaced, to phrase it in the same way you did.
You are right that \r\r\n would not be proper, which is why he wrote the
code to avoid creating instances of that.
Personally, I think it's overkill. If you're going to the trouble of
using the general purpose "Environment.NewLine" property as the replaced
text, then checking to avoid munging a specific character combination
(\r\n) seems pointless, given that in theory the point is that
"Environment.NewLine" might not actually be that specific character
combination. If nothing else, I would think it would make more sense to
design the code to replace *both* \n and \r\n with Environement.NewLine.
But ignoring that point, the code does do exactly what Arne says it does.
Pete