Despite these exceptions you are blindly using environment.newline?
Those exceptions are the cases where the programmer purposely overrode
the convention. I have never had that happen, since most people use the
standard IO conventions of there platform. And I only use
Environment.NewLine for output. Not for reading, espcially since
StreamReader is usually capable of descerning the source files newline
character.
I'm talking about conventions in general, not only about the Framework.
There are apps not built on the Framework.
I'm not talking about the Framework either. I'm talking about the
standard system libraries on *nix and windows systems. I'm talking
about the low level IO.
Even if there was only 1 exception among 100,000 cases, I'd have to check
the format in each case.
In general, I think your going to find that the ratio is even smaller
then that.
The file format - and this is only an example where line terminators are
used - is independent from managed code, unmanaged code, interop,
programming language ...
Yes. You have to be aware of what the terminator is going to be if you
getting data from other platforms. Like I said, usually when I do file
IO on *nix, the files are intended to be used with windows software - so
I generally use the CR/LF sequence in those cases.
You /always/ have to be aware of the format, not only when dealing wit
hcross platfrom data.
Not really - unless you specifically override the terminator. And there
would have to be a very good reason for me to do that if I knew the data
was going to another *nix system, since every standard tool on that
system is going to expect lf as the terminator character. The only time
that is in issue is if your dealing with different platforms.
Right, just because of this lack, you always have to know what to expect.
Yes - if your recieving data from other platforms, then yes you have to
be aware of the issue. I've never had a file from a windows source that
did not use the CR/LF convention.
As long as there is no guarantee that a file (or the programmer writing the
file) obeys the convention, you can not blindly use environment.newline.
The only time this is an issue is in recieving data. You have to know
when reading data what the terminator was when writing. As I said, most
of the time the data that I write on *nix is destined for windows boxes
- so I usually use a CR/LF explicitly so that the file will work with
the standard windows tools - such as notepad. I have noticed that
wordpad is smart enough to recognize a single lf though
1. Even if you know the platfoom, you will fail if you rely on this. My
attitude is that a high probabibilty is not enough. That's why I say that I
have to check each case.
In very, very few cases. I'm not advocating that you not check your
source file.
2. You sometimes don't know on which platform the file has been created. I
don't have to know it but I have to know the used seperator.
"Environment.newline" says absolutely nothing.
Of course not. It only tells you the newline character of the current
platform - not the one where the file originated. For cross platform
data - you do have to know the format it was written in. But the
newline character used is a very good indication of the originating
platform.
I also say this because I recently read a file using the streamreader
(readline method) and found out that the streamreader also recognizes a
single CR as a separator. Hmmm...... According to your definition it's a
bug, isn't it? (BTW, ran on a Win32 platform ;-) )
I don't think so. I think that ReadLine is a bit smarter then that. It
says in the docs that it looks for LF ("\n") or CRLF ("\r\n") as the
line terminator. Which means it is not soley using Environment.NewLine.
