what char == newline?

[mp]

stepping through characters in a string (from contents of ascii text file)
i'm trying to detect the linebreaks
i tried
if (currentCharacter == '\n')
{
Log.WriteLine("end of line");
}

and

if (currentCharacter.ToString() == Environment.NewLine)
{
Log.WriteLine("end of line");
}

and

if (currentCharacter == '\r')
{
Log.WriteLine("end of line");
}

how can I detect a llinebreak when i'm reading each character in turn?

thanks

mark

 

[mp]

nevermind,
streamreader.ReadLine doesn't include the linebreak chars...duh!
sorry
mark

 

[Jeff Johnson]

how can I detect a llinebreak when i'm reading each character in turn?

To answer this specific question, you have to recognize when you get the
first character of the line break sequence and then "peek" at the next
character to see if it matches as well. I realize you found the answer, but
this is the process if you ever need to roll your own.

 

[mp]

To answer this specific question, you have to recognize when you get the
first character of the line break sequence and then "peek" at the next
character to see if it matches as well. I realize you found the answer,
but this is the process if you ever need to roll your own.

thanks

I was totally brainfarting on the question in the first place as I'd
forgotten i was using ReadLine and it didn't include the linebreaks


if i was reading the whole file including breaks:
you're saying, i'd look first for '\r' then for '\n' right?
why would't '\r' be enough?
how could an '\r' by itself be hanging out in a file?
doesn't that (carriage return) basically erase the preceeding line and
replace with the next line input if it were just there by itself?

fwiw anyhow in my case what i did was, since this test is in a function that
just receives a character as input, the function does'nt know where in the
line the character came from
so now i'm also passing in the position of the character, if it's 0 then
this is the beginning of a new line...probably a goofy way to do it but the
only thing i could think of, for this function to know when it's at the end
(actually beginning) of a line

mark

 

[Arne Vajhøj]

streamreader.ReadLine doesn't include the linebreak chars...duh!
sorry

For good reasons.

Line separators are file system specific.

Windows, DOS uses CR LF
Unix, Linux etc. uses LF
Old MacOS uses CR
many other systems does not use line separators at all but instead uses
counted formats (they may emulate *nix behavior in the C RTL though)

Arne

 

[Arne Vajhøj]

if i was reading the whole file including breaks:
you're saying, i'd look first for '\r' then for '\n' right?
why would't '\r' be enough?
how could an '\r' by itself be hanging out in a file?

It is a valid character in text files on most
systems (except old MacOS ones).

Arne

 

[Jeff Johnson]

how could an '\r' by itself be hanging out in a file?

HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA!!!!!

Clearly you've never dealt with data "in the wild." I've seen all sorts of
crap.

doesn't that (carriage return) basically erase the preceeding line and
replace with the next line input if it were just there by itself?

The carriage return is a throwback to when printers (and typewriters,
remember them?) actually had...CARRIAGES! Its only function is to bring the
print head back to the left. Without a line feed after it you'd start
overtyping the current line.

 

[Jeff Johnson]

It is a valid character in text files on most
systems (except old MacOS ones).

Actually, in old MacOS systems it was THE line break character. Modern
MacOSes use the *NIX standard LF.

(After I wrote that I'm wondering if that's what you meant: that CR was not
a valid PRINTABLE character but rather the line break character. If so,
ignore the "correction.")

 

[Arne Vajhøj]

Actually, in old MacOS systems it was THE line break character. Modern
MacOSes use the *NIX standard LF.

(After I wrote that I'm wondering if that's what you meant: that CR was not
a valid PRINTABLE character but rather the line break character. If so,
ignore the "correction.")

It is not a valid non-printable character in a text line
either - it is meta data.

But that was my point.

Arne