eof character in c#

[dev_kh]

Hi,

I am facing a weird issue. Here it goes:

I am writing a c# app for a client with which I will read some data and
generate a .dat file for them from that data. Then the client will read that
..dat file and do something based on it's contents at their end. My
application will run on a windows xp machine but client should be able to
read this dat file in unix box. So, they want to know what will be the end
of line character (which I said will be standard \r\n), but they also insist
on knowing what is enf of file character.

Now, I have read that there is no specal EOF character in c#, so what should
I tell my client. They said they need to know all this as they will be
reading this dat file on a unix box.

Please enlighten me.

Thanks
dev_kh

[Mark Monster]

Hello dev_kh,

I'm one hundred percent sure there is not EOF character in C#. There is no
need for it too. Just read the file till there is nothing left. That's all.

Regards,

Mark Monster

Hi,

I am facing a weird issue. Here it goes:

I am writing a c# app for a client with which I will read some data
and generate a .dat file for them from that data. Then the client
will read that .dat file and do something based on it's contents at
their end. My application will run on a windows xp machine but client
should be able to read this dat file in unix box. So, they want to
know what will be the end of line character (which I said will be
standard \r\n), but they also insist on knowing what is enf of file
character.

Now, I have read that there is no specal EOF character in c#, so what
should I tell my client. They said they need to know all this as they
will be reading this dat file on a unix box.

Please enlighten me.

Thanks
dev_kh

[Oliver Sturm]

dev_kh wrote:

I am facing a weird issue. Here it goes:

I am writing a c# app for a client with which I will read some data and
generate a .dat file for them from that data. Then the client will read
that
.dat file and do something based on it's contents at their end. My
application will run on a windows xp machine but client should be able to
read this dat file in unix box. So, they want to know what will be the end
of line character (which I said will be standard \r\n), but they also
insist
on knowing what is enf of file character.

Now, I have read that there is no specal EOF character in c#, so what
should
I tell my client. They said they need to know all this as they will be
reading this dat file on a unix box.

Having an EOF character or not doesn't have anything to do with using C#,
or Unix, or whatever. It's just a schema that uses a special character to
signal the end of a file. I'm not entirely sure where that originally came
from, but it might have been serial communications - a pattern similar to
the xon/xoff characters that were used when there were not RTS/CTS lines
available.

Now, if those guys want an EOF character, just write one to the file.
Obviously, this character must be cleary distinguishable from the other
data in the file, so the choice might not be an easy one. It would
certainly be easier if they could just use file IO methods that can find
the end of a file without the help of such a character, but if they can't
do it, it's no problem to write the character yourself.

Oliver Sturm
--
Expert programming and consulting services available
See http://www.sturmnet.org (try /blog as well)

[dev_kh]

Thanks Guys for replying to my query. I know that there is no need for EOF
in c# and I do not want to write one (becuase of hassle of choosing which
unique character to identify as EOF and also because I will need to update
this file continuosly and I do not want to have to find this EOF and then
move it every time I update the file). The problem is that my clients will
read this .dat file (which will be generated on a windows machine) on their
unix machine. So that's why they are insisting on finding out which is the
EOF character. Any opinions about the same. I did some research and told
them that in windows by default ASCII 26 i.e. CTRL + Z is inserted
automatically as EOF. Now, if they want they can find the unix equivalent
of this ASCII 26 and look for it in my c# generated .dat file.

Did I take right approach...
Thanks
dev

"Oliver Sturm" wrote:

dev_kh wrote:

I am facing a weird issue. Here it goes:

I am writing a c# app for a client with which I will read some data and
generate a .dat file for them from that data. Then the client will read
that
.dat file and do something based on it's contents at their end. My
application will run on a windows xp machine but client should be able to
read this dat file in unix box. So, they want to know what will be the end
of line character (which I said will be standard \r\n), but they also
insist
on knowing what is enf of file character.

Now, I have read that there is no specal EOF character in c#, so what
should
I tell my client. They said they need to know all this as they will be
reading this dat file on a unix box.

Having an EOF character or not doesn't have anything to do with using C#,
or Unix, or whatever. It's just a schema that uses a special character to
signal the end of a file. I'm not entirely sure where that originally came
from, but it might have been serial communications - a pattern similar to
the xon/xoff characters that were used when there were not RTS/CTS lines
available.

Now, if those guys want an EOF character, just write one to the file.
Obviously, this character must be cleary distinguishable from the other
data in the file, so the choice might not be an easy one. It would
certainly be easier if they could just use file IO methods that can find
the end of a file without the help of such a character, but if they can't
do it, it's no problem to write the character yourself.

Oliver Sturm
--
Expert programming and consulting services available
See http://www.sturmnet.org (try /blog as well)

[Oliver Sturm]

dev_kh wrote:

Thanks Guys for replying to my query. I know that there is no need for EOF
in c# and I do not want to write one (becuase of hassle of choosing which
unique character to identify as EOF and also because I will need to update
this file continuosly and I do not want to have to find this EOF and then
move it every time I update the file). The problem is that my clients will
read this .dat file (which will be generated on a windows machine) on their
unix machine. So that's why they are insisting on finding out which is the
EOF character. Any opinions about the same. I did some research and told
them that in windows by default ASCII 26 i.e. CTRL + Z is inserted
automatically as EOF. Now, if they want they can find the unix equivalent
of this ASCII 26 and look for it in my c# generated .dat file.

Did I take right approach...

Well, this used to be used on DOS and Windows as an EOF character. But a
normal file that you generate today doesn't have this character attached
to it, so they won't be able to find it in your file. If you want to do
these guys a favour, you'll have to write the byte to the file yourself.
Oliver Sturm
--
Expert programming and consulting services available
See http://www.sturmnet.org (try /blog as well)

[dev_kh]

Hi Oliver,

Thanks a lot for the reply. It will be painful to go back and tell them
about the same. But I guess I'll have to do that. Also, do you know what
will they need to do at their end (in unix) to find out if the end of file is
reached in the .dat file created by my c# file.

Also, you said that this used to be the norm in windows but not any more..
so does that mean that any file I create now using c# or manually in notepad,
text pad etc will not have a eof... Or is it only .net that removes the eof
from the generated files... Please confirm..

More thanks than words
Neha

"Oliver Sturm" wrote:

dev_kh wrote:

Thanks Guys for replying to my query. I know that there is no need for EOF
in c# and I do not want to write one (becuase of hassle of choosing which
unique character to identify as EOF and also because I will need to update
this file continuosly and I do not want to have to find this EOF and then
move it every time I update the file). The problem is that my clients will
read this .dat file (which will be generated on a windows machine) on their
unix machine. So that's why they are insisting on finding out which is the
EOF character. Any opinions about the same. I did some research and told
them that in windows by default ASCII 26 i.e. CTRL + Z is inserted
automatically as EOF. Now, if they want they can find the unix equivalent
of this ASCII 26 and look for it in my c# generated .dat file.

Did I take right approach...

Well, this used to be used on DOS and Windows as an EOF character. But a
normal file that you generate today doesn't have this character attached
to it, so they won't be able to find it in your file. If you want to do
these guys a favour, you'll have to write the byte to the file yourself.
Oliver Sturm
--
Expert programming and consulting services available
See http://www.sturmnet.org (try /blog as well)

[dev_kh]

Also, do you know at what point was the eof char removed. My client could
run this c# app on win 2000 or win xp machine or even a windoes 2000/2003
server and then mail this dat file on a unix box and read it there...

Thanks
dev

"dev_kh" wrote:

Hi Oliver,

Thanks a lot for the reply. It will be painful to go back and tell them
about the same. But I guess I'll have to do that. Also, do you know what
will they need to do at their end (in unix) to find out if the end of file is
reached in the .dat file created by my c# file.

Also, you said that this used to be the norm in windows but not any more..
so does that mean that any file I create now using c# or manually in notepad,
text pad etc will not have a eof... Or is it only .net that removes the eof
from the generated files... Please confirm..

More thanks than words
Neha

"Oliver Sturm" wrote:

dev_kh wrote:

Thanks Guys for replying to my query. I know that there is no need for EOF
in c# and I do not want to write one (becuase of hassle of choosing which
unique character to identify as EOF and also because I will need to update
this file continuosly and I do not want to have to find this EOF and then
move it every time I update the file). The problem is that my clients will
read this .dat file (which will be generated on a windows machine) on their
unix machine. So that's why they are insisting on finding out which is the
EOF character. Any opinions about the same. I did some research and told
them that in windows by default ASCII 26 i.e. CTRL + Z is inserted
automatically as EOF. Now, if they want they can find the unix equivalent
of this ASCII 26 and look for it in my c# generated .dat file.

Did I take right approach...

Well, this used to be used on DOS and Windows as an EOF character. But a
normal file that you generate today doesn't have this character attached
to it, so they won't be able to find it in your file. If you want to do
these guys a favour, you'll have to write the byte to the file yourself.
Oliver Sturm
--
Expert programming and consulting services available
See http://www.sturmnet.org (try /blog as well)

[Oliver Sturm]

So, I guess I found out what kind of problem these guys have. The thing
is, I had actually forgotten some stuff as well...

I wrote this small (C) program on my Unix machine:

#include <stdio.h>

void main() {
FILE * file;
int c;

file = fopen("eof.txt", "r");

while ((c = fgetc(file)) != EOF)
printf("Character %d, '%c'\n", c, (unsigned char) c);

fclose(file);
}

This is a standard pattern to load data from a file in C, character by
character in this case. Looking at it cursorily, you might think there has
to be a character in the file that gets read last and equals the EOF
macro... not!

In fact, this character is not in the file, but it's created automatically
by the file IO subsystem to signal the end of the file to the caller. In
fact, the fgetc method returns an int instead of a char or an unsigned
char to be able to return this kind of information to the caller without
having to take anything out of the range of valid values.

Obviously I can only guess, but maybe that's the problem these people are
seeing. Of course it's also possible that their algorithm needs, for some
reason, a special character terminating the file, but in that case they
should be telling you which character that is... if all they want to do is
read your file, I can't see what the problem is supposed to be.
Oliver Sturm
--
Expert programming and consulting services available
See http://www.sturmnet.org (try /blog as well)

[dev_kh]

Hi Oliver,

Many Many Many thanks for taking the time out to write this code. You are
the best. So, in ran the similar thought to the client and I am waiting to
hear from them. But I was also thinking that if EOF is not a character, then
atleast there should be a EOF() function in most of the languages which
should be able to tell if that condition is reached. Right.

Thanks
dev

"Oliver Sturm" wrote:

So, I guess I found out what kind of problem these guys have. The thing
is, I had actually forgotten some stuff as well...

I wrote this small (C) program on my Unix machine:

#include <stdio.h>

void main() {
FILE * file;
int c;

file = fopen("eof.txt", "r");

while ((c = fgetc(file)) != EOF)
printf("Character %d, '%c'\n", c, (unsigned char) c);

fclose(file);
}

This is a standard pattern to load data from a file in C, character by
character in this case. Looking at it cursorily, you might think there has
to be a character in the file that gets read last and equals the EOF
macro... not!

In fact, this character is not in the file, but it's created automatically
by the file IO subsystem to signal the end of the file to the caller. In
fact, the fgetc method returns an int instead of a char or an unsigned
char to be able to return this kind of information to the caller without
having to take anything out of the range of valid values.

Obviously I can only guess, but maybe that's the problem these people are
seeing. Of course it's also possible that their algorithm needs, for some
reason, a special character terminating the file, but in that case they
should be telling you which character that is... if all they want to do is
read your file, I can't see what the problem is supposed to be.
Oliver Sturm
--
Expert programming and consulting services available
See http://www.sturmnet.org (try /blog as well)

[Oliver Sturm]

dev_kh wrote:

Many Many Many thanks for taking the time out to write this code. You are
the best. So, in ran the similar thought to the client and I am waiting to
hear from them. But I was also thinking that if EOF is not a character,
then
atleast there should be a EOF() function in most of the languages which
should be able to tell if that condition is reached. Right.

There's actually a function feof() in C, which does this, kind of. I say
"kind of" because the function works in a specific way... it's really
easier, and also results in a simple and intuitive syntax, to look out for
the EOF special value. You only need to be aware that this value won't
usually be in the actual file stream, but generated by lower level file IO
to signal a state.
Oliver Sturm
--
Expert programming and consulting services available
See http://www.sturmnet.org (try /blog as well)

[dev_kh]

Many Thanks Oliver. My client says that they are fine with CTRL Z (ASCII 26)
to indicate the EOF condition. I also explained that they might have to use
the eof() function to determine that state and they said they are ok with it.
So now we will go with that. If later they cannot determine when the end of
file has reached then I will probably insert anything like CTRL Z or "END OF
FILE" as a trailer in the file for them. Everything is possible in the world
of consultancy. Joys.

Thanks
dev

"Oliver Sturm" wrote:

dev_kh wrote:

Many Many Many thanks for taking the time out to write this code. You are
the best. So, in ran the similar thought to the client and I am waiting to
hear from them. But I was also thinking that if EOF is not a character,
then
atleast there should be a EOF() function in most of the languages which
should be able to tell if that condition is reached. Right.

There's actually a function feof() in C, which does this, kind of. I say
"kind of" because the function works in a specific way... it's really
easier, and also results in a simple and intuitive syntax, to look out for
the EOF special value. You only need to be aware that this value won't
usually be in the actual file stream, but generated by lower level file IO
to signal a state.
Oliver Sturm
--
Expert programming and consulting services available
See http://www.sturmnet.org (try /blog as well)