EOF (novice)

[Ed Morton]

Ctrl-c works just fine.

Typing Ctrl-D is usually, but not always, how to provide an EOF. Typing that
when manually entering input is just like if you ran your program redirecting
input from a text file instead of typing it you'd get an EOF at the end of the
input stream. Typing Ctrl-C (or "Ctrl-?" or "Del" or whatever your interrupt
keystroke happens to be) interrupts the running process just like it would if
that process were exeucting a shell script instead of a C program.

But absolutely nothing was said about this

in K&R or the FAQ.

Well, no, it wouldn't be. It isn't a C issue, it's a UNIX one, and it's a
question that I've never seen asked before in this NG so it wouldn't qualify as
"Frequently Asked". It is, however, addressed in the ksh manual page:

eof End-of-file character, normally ^D, is processed
as an End-of-file.....

Regards,

Ed.

 

[Kevin Bracey]

In message <[email protected]>

Because neither of those 'keystrokes' (or any others)
are defined by the language. They're defined by the
host operating system.

Not necessarily. My OS doesn't have a concept of EOF for terminal input
at all. C assumes one for trivial programs like that, so the C library
itself decides to follow the Unix Ctrl-D convention. I'd agree that this
should be in the FAQ - for many non-Unix systems, terminal EOF is a purely
"C" concept.

I'd been using C for over a year on my platform before I found out about
Ctrl-D; I'd hitherto assumed that EOF wasn't possible on stdin.

 

[John Bode]

You are missing my point: The program as written in K&R *doesn't
work*. Or it seems not to.

It works *just fine*. If you generate an EOF, it will terminate. The
details of how to generate an EOF on a particular system is beyond the
scope of that particular tutorial. Sorry that got past you.

That part of the book is POORLY WRITTEN. Lame.

Maybe you'd prefer Herb Schildt? He's an excellent writer, he just
doesn't know C very well.

That's bizarre, but why not? The KB is only *standard* input.

Except for systems where it isn't. Think about any number of embedded
controllers, modems, etc. All The World Is NOT An x86 Desktop System.

[snip rest]

 

[Dan Pop]

In message <[email protected]>


Not necessarily. My OS doesn't have a concept of EOF for terminal input
at all. C assumes one for trivial programs like that, so the C library
itself decides to follow the Unix Ctrl-D convention. I'd agree that this
should be in the FAQ - for many non-Unix systems, terminal EOF is a purely
"C" concept. ^^^^

Are there so many such systems? The concept seems to predate Unix
and C by a large margin and I've used plenty of systems, some of
them having nothing in common with Unix and not providing a C
implementation at all, but all of them had one way or another of
signaling end of file on the standard input (even the punch card
based ones). The only exceptions I can think of are micros using a BASIC
interpreter instead of an operating system.

I'd been using C for over a year on my platform before I found out about
Ctrl-D; I'd hitherto assumed that EOF wasn't possible on stdin.

Reading the implementation's documentation can be a rewarding exercise ;-)

Dan

 

[CBFalconer]

.... snip ...

Not necessarily. My OS doesn't have a concept of EOF for terminal
input at all. C assumes one for trivial programs like that, so the
C library itself decides to follow the Unix Ctrl-D convention. I'd
agree that this should be in the FAQ - for many non-Unix systems,
terminal EOF is a purely "C" concept.

I rather doubt that. However, nothing insists that you can
generate such a signal from the keyboard; it may require physical
destruction of something.

I'd been using C for over a year on my platform before I found out
about Ctrl-D; I'd hitherto assumed that EOF wasn't possible on
stdin.

Some systems hide the mechanism. On the HP3000 under MPE it
required ":EOF" at the prompt, after which the terminal was
useless until action was taken by the system operator or the whole
system was taken down and reinitialized. Very useful for playing
pranks. It also meant that you used something else to signal "end
of input".

 

[Alan Connor]

<snip>

Thanks, James.

AC

 

[Alan Connor]

<snip>

Mr. Falconer. This is the third post in a row I have gotten from you that
is abusive in nature.

Stick them where the sun don't shine and get the **** out of my life.

killfiled for 90 days.


AC

 

[Alan Connor]

<snip>

Thanks, Ed. That was helpful.

AC

 

[Alan Connor]

<snip>

Point taken, John. Thank you.

AC

 

[Richard Heathfield]

Stick them where the sun don't shine and get the **** out of my life.

Please don't use foul language on this newsgroup.

Thank you.

 

[Joona I Palaste]

Alan Connor wrote:

Alan, I believe that one with your less-than-adequate skills in C
programming is hardly in a position to insult comp.lang.c regulars in a
technical forum.

 

[Christopher Benson-Manica]

Please don't use foul language on this newsgroup.

If everyone KF'ed him and no one responded, it would be a moot
point...

 

[Joona I Palaste]

Connor. In case you haven't noticed, stating simple facts (i.e. that C
and Unix are different things, despite what you think) is not being
abusive.

 

[Sheldon Simms]

<snip>

Mr. Falconer. This is the third post in a row I have gotten from you that
is abusive in nature.

Stick them where the sun don't shine and get the **** out of my life.

killfiled for 90 days.

I'm getting tired of reading your abusive posts in this newsgroup

killfiled for 30 days.

And don't talk back or I'll send you to your room for another 30 days.

 

[Lew Pitcher]

Ctrl-c works just fine. But absolutely nothing was said about this
in K&R or the FAQ.

Alan, that's because the physical implementation of the control that generates
the "End-of-file" condition is /not/ part of C; it's part of the operating
environment (OS, shell, etc.)

Knowing that you are using Linux, you should have looked at the Linux
documentation, where you would find...

~ $ man stty
STTY(1) FSF STTY(1)

NAME
stty - change and print terminal line settings

...

DESCRIPTION
Print or change terminal characteristics.
...
eof CHAR
CHAR will send an end of file (terminate the input)

and
~ $ stty -a
speed 38400 baud; rows 24; columns 80; line = 0;
intr = ^C; quit = ^\; erase = ^H; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W;
lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread -clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon
-ixoff
-iuclc -ixany -imaxbel
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0
ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt
echoctl echoke

Note the 2nd line of the stty -a results:
"eof = ^D;"

The "End of File" character is configurable in Linux (as in Unix), and
defaults to ^D. It's an OS setting, and not part of C.

--
Lew Pitcher

Master Codewright and JOAT-in-training
Registered Linux User #112576 (http://counter.li.org/)
Slackware - Because I know what I'm doing.

 

[CBFalconer]

<snip>

killfiled for 90 days.

Whee! I made it.

 

[Richard Heathfield]

If everyone KF'ed him and no one responded, it would be a moot
point...

....and he would then be at liberty to dispense all the crap C advice he
wanted, with nobody to correct him.

 

[Richard Heathfield]

I'm getting tired of reading your abusive posts in this newsgroup

killfiled for 30 days.

And don't talk back or I'll send you to your room for another 30 days.

He's already in his room. I doubt very much whether he's allowed downstairs
except for meals.

 

[Kevin Bracey]

Reading the implementation's documentation can be a rewarding exercise ;-)

I don't think it's actually in the documentation. I could be wrong though.

Any RISC OS users out there spotted it in the compiler manuals or
programmer's reference manual?

 

[Lew Pitcher]

In message <[email protected]>



I don't think it's actually in the documentation. I could be wrong though.

Any RISC OS users out there spotted it in the compiler manuals or
programmer's reference manual?

You probably won't find it in either of those manuals. You'll likely find
the doc on how to generate the EOF signal in whatever RISC OS 'user' manuals
are out there. Since the EOF condition is something that the OS reports to
the runtime/application, its generation will be specific to the OS (although
the mechanism that the OS uses to signal EOF to the runtime may be discussed
in the documentation for the runtime). How the OS determines EOF will be
documented in the OS documentation.