By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
454,445 Members | 1,329 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 454,445 IT Pros & Developers. It's quick & easy.

Pass an EOF before pressing enter

P: n/a
Hi all,

I'll get straight into it.

When I try to run the code:
.....
while (scanf("%c", &c) == 1)
printf("%c", c);
.....
I input "abcd" follows by an EOF(Ctrl + d) instead of pressing enter,
and the program prints "abcd" on the screen. And then I pass an EOF
signal the program ends.

My question is why doesn't the program end the first it encounters the
EOF after the "abcd"?
And also if I DO press enter after "abcd", do I pass the characters
'a', 'b', 'c', 'd', '\n' to the program?

Any suggestions are appreciated.

Dec 31 '06 #1
Share this Question
Share on Google+
9 Replies


P: n/a
Camellia wrote:
>
When I try to run the code:
....
while (scanf("%c", &c) == 1)
printf("%c", c);
....
I input "abcd" follows by an EOF(Ctrl + d) instead of pressing
enter, and the program prints "abcd" on the screen. And then I
pass an EOF signal the program ends.

My question is why doesn't the program end the first it encounters
the EOF after the "abcd"?
Because you may really want to input a ^d it is only an EOF signal
when presented at the beginning of a line. You probably had to hit
ENTER (or return) after the first ^d.
>
And also if I DO press enter after "abcd", do I pass the characters
'a', 'b', 'c', 'd', '\n' to the program?
Yes.

--
Merry Christmas, Happy Hanukah, Happy New Year
Joyeux Noel, Bonne Annee.
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home.att.net>
Dec 31 '06 #2

P: n/a
CBFalconer wrote:
Camellia wrote:

When I try to run the code:
....
while (scanf("%c", &c) == 1)
printf("%c", c);
....
I input "abcd" follows by an EOF(Ctrl + d) instead of pressing
enter, and the program prints "abcd" on the screen. And then I
pass an EOF signal the program ends.

My question is why doesn't the program end the first it encounters
the EOF after the "abcd"?

Because you may really want to input a ^d it is only an EOF signal
when presented at the beginning of a line. You probably had to hit
ENTER (or return) after the first ^d.

And also if I DO press enter after "abcd", do I pass the characters
'a', 'b', 'c', 'd', '\n' to the program?

Yes.

--
Merry Christmas, Happy Hanukah, Happy New Year
Joyeux Noel, Bonne Annee.
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home.att.net>
Thanks Chuck for helping us newbies, and others :)

I was noticing something like the above also happening as I am going
through C book (KR2) examples as well. After reading this email I was
experimenting with the following program:
#include <stdio.h>
main()
{
int c;
while ( (c = getchar()) != EOF) {
putchar(c);
}
}
While running in the bash shell (I also tried cshell), if I type
characters, and then enter button, it prints characters I just entered,
then if I ctrl-d, it gives me the shell prompt. If I enter characters,
then ctrl-d, it will print characters, but no shell prompt. I can
repeat the pattern over and over until I enter two consecutive ctrl-d,
which will then print chars then give me a prompt.

Jan 1 '07 #3

P: n/a
vlsidesign said:

<snip>
While running in the bash shell (I also tried cshell), if I type
characters, and then enter button, it prints characters I just entered,
then if I ctrl-d, it gives me the shell prompt. If I enter characters,
then ctrl-d, it will print characters, but no shell prompt. I can
repeat the pattern over and over until I enter two consecutive ctrl-d,
which will then print chars then give me a prompt.
The exact mechanics of how you tell a shell to signify end-of-input to a
running process are really a question for a group dedicated to your
platform (or, indeed, to your shell, if it's a many-shelled platform).

We generally get as far as saying "try ^D (or ^Z for DOS/Win32) and see what
happens", but an in-depth discussion of shells would be beyond the scope of
comp.lang.c.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.
Jan 1 '07 #4

P: n/a
CBFalconer wrote:
Camellia wrote:
>When I try to run the code:
....
while (scanf("%c", &c) == 1)
printf("%c", c);
....
I input "abcd" follows by an EOF(Ctrl + d) instead of pressing
enter, and the program prints "abcd" on the screen. And then I
pass an EOF signal the program ends.

My question is why doesn't the program end the first it encounters
the EOF after the "abcd"?

Because you may really want to input a ^d it is only an EOF signal
when presented at the beginning of a line. You probably had to hit
ENTER (or return) after the first ^d.
This is not accurate and yet no-one seems to have corrected it yet. It's
a good illustration of why not to try to address system-specifics on
comp.lang.c.

<OT>
Ctrl-d never has the function of actually inputting a Ctrl-d character
(ASCII EOT) and so the reason it appears to only be an EOF signal when
presented at the beginning of a line has nothing to do with anyone
really wanting to input a Ctrl-d character.

Ctrl+d has the effect of an EOF signal only when the line buffer is
empty. The line buffer can become empty in at least three ways:
1. By pressing Enter, which sends the contents of the line
buffer followed by '\n' and clears the line buffer, or
2. By pressing Ctrl+d, which sends the contents of the line
buffer without appending '\n' and clears the line buffer.
3. By pressing Backspace enough times to delete the contents.

The basic function of Ctrl+d is "flush buffer". If you try to flush the
buffer when it is already empty, that results in a read of zero bytes,
which is interpreted as an end-of-file condition.
</OT>

--
Simon.
Jan 2 '07 #5

P: n/a
Simon Biber <ne**@ralmin.ccwrites:
[...]
This is not accurate and yet no-one seems to have corrected it
yet. It's a good illustration of why not to try to address
system-specifics on comp.lang.c.
Indeed. Here's another illustration:
<OT>
Ctrl-d never has the function of actually inputting a Ctrl-d character
(ASCII EOT)
It does in raw mode, or following a Ctrl-V, or if the EOF character is
configured (by the "stty" command) to something other than Ctrl-D.

[...]
</OT>
And if I'm mistaken, it just proves the point even further. 8-)}

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Jan 2 '07 #6

P: n/a
Simon Biber wrote:
CBFalconer wrote:
Camellia wrote:
When I try to run the code:
....
while (scanf("%c", &c) == 1)
printf("%c", c);
....
I input "abcd" follows by an EOF(Ctrl + d) instead of pressing
enter, and the program prints "abcd" on the screen. And then I
pass an EOF signal the program ends.

My question is why doesn't the program end the first it encounters
the EOF after the "abcd"?
Because you may really want to input a ^d it is only an EOF signal
when presented at the beginning of a line. You probably had to hit
ENTER (or return) after the first ^d.

This is not accurate and yet no-one seems to have corrected it yet. It's
a good illustration of why not to try to address system-specifics on
comp.lang.c.

<OT>
Ctrl-d never has the function of actually inputting a Ctrl-d character
(ASCII EOT) and so the reason it appears to only be an EOF signal when
presented at the beginning of a line has nothing to do with anyone
really wanting to input a Ctrl-d character.

Ctrl+d has the effect of an EOF signal only when the line buffer is
empty. The line buffer can become empty in at least three ways:
1. By pressing Enter, which sends the contents of the line
buffer followed by '\n' and clears the line buffer, or
2. By pressing Ctrl+d, which sends the contents of the line
buffer without appending '\n' and clears the line buffer.
3. By pressing Backspace enough times to delete the contents.

The basic function of Ctrl+d is "flush buffer". If you try to flush the
buffer when it is already empty, that results in a read of zero bytes,
which is interpreted as an end-of-file condition.
</OT>

--
Simon.
Thanks for clearing it up. I'm a newbie going through the famous
Kernighan & Richie C book, and I was very curious about that behavior
as well. I guess a question like this should perhaps be posted in a
group for the bash or C shell that we are running the C program in,
right??

Jan 2 '07 #7

P: n/a
Simon Biber wrote:
CBFalconer wrote:
.... snip ...
>>
Because you may really want to input a ^d it is only an EOF signal
when presented at the beginning of a line. You probably had to hit
ENTER (or return) after the first ^d.

This is not accurate and yet no-one seems to have corrected it yet.
It's a good illustration of why not to try to address
system-specifics on comp.lang.c.

<OT>
Ctrl-d never has the function of actually inputting a Ctrl-d
character (ASCII EOT) and so the reason it appears to only be an
EOF signal when presented at the beginning of a line has nothing to
do with anyone really wanting to input a Ctrl-d character.

Ctrl+d has the effect of an EOF signal only when the line buffer is
empty. The line buffer can become empty in at least three ways:
1. By pressing Enter, which sends the contents of the line
buffer followed by '\n' and clears the line buffer, or
2. By pressing Ctrl+d, which sends the contents of the line
buffer without appending '\n' and clears the line buffer.
3. By pressing Backspace enough times to delete the contents.

The basic function of Ctrl+d is "flush buffer". If you try to flush
the buffer when it is already empty, that results in a read of zero
bytes, which is interpreted as an end-of-file condition.
</OT>
Your answer is at least as system specific as mine. The point is
that it normally is only used as an EOF signal at the beginning of
a line. Same for the use of ^z under DOS/Windows. The HP3000 used
':', or could be set to insist on ":EOF". After which regaining
your terminal required operator intervention :-)

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>
Jan 2 '07 #8

P: n/a
"vlsidesign" <fo*****@gmail.comwrites:
Simon Biber wrote:
[snip]
>Ctrl+d has the effect of an EOF signal only when the line buffer is
empty. The line buffer can become empty in at least three ways:
[snip]
>
Thanks for clearing it up. I'm a newbie going through the famous
Kernighan & Richie C book, and I was very curious about that behavior
as well. I guess a question like this should perhaps be posted in a
group for the bash or C shell that we are running the C program in,
right??
<OT>
It's not a shell issue, it's an operating system issue.
comp.unix.programmer would be the place to ask about it (assuming you
don't find the information you need in your system's documentation,
which should be the first thing you try).
</OT>

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Jan 2 '07 #9

P: n/a
In article <45***************@yahoo.com>,
CBFalconer <cb********@maineline.netwrote:
>>Because you may really want to input a ^d it is only an EOF signal
when presented at the beginning of a line. You probably had to hit
ENTER (or return) after the first ^d.
[...]
>Ctrl+d has the effect of an EOF signal only when the line buffer is
empty. The line buffer can become empty in at least three ways:
1. By pressing Enter, which sends the contents of the line
buffer followed by '\n' and clears the line buffer, or
2. By pressing Ctrl+d, which sends the contents of the line
buffer without appending '\n' and clears the line buffer.
3. By pressing Backspace enough times to delete the contents.
>Your answer is at least as system specific as mine.
But it has the advantage over yours of being correct, unless you were
referring to some non-unix system.

-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.
Jan 2 '07 #10

This discussion thread is closed

Replies have been disabled for this discussion.