Reading stdin once confuses second stdin read

[Charlie Zender]

Hi,

I have a program which takes the output filename argument from stdin.
Once the program knows the output filename, it tries to open it.
If the output file exists, the program asks the user to confirm
whether he really wants to overwrite the existing output file.
The problem is that the second read from stdin, to obtain the user
response whether to overwrite the existing output file, never
waits for the user's response. It's as if a bunch of characters
that are sitting in stdin get read before the user can respond.
I've tried strategically placing fflush(stdin) and fclose(stdin)
to fix the problem, but these fixes do not work.
I think there is something subtle about reading/flushing/closing
stdin that I do not understand. Any ideas?

Thanks,
Charlie

The logic looks like this:

User types...

echo "file_in" | my_program -o file_out

my_program uses fscanf to read stdin for the input filename---

while((cnv_nbr=fscanf(stdin,"%256s\n",bfr_in)) != EOF){
file_in=(char *)strdup(bfr_in);
}

my_program then opens file_in, does a lot of work (but does not
touch stdin again) until it eventually tries to write it to
file_out. If file_out already exists, user is queried and program
reads user response from stdin:

rcd=stat(file_out,&stat_sct);
if(rcd != -1){
fprintf(stdout,"File already exists---`o'verwrite (y/n)?");
usr_reply=(char)fgetc(stdin);
}

However, the fgetc() does not wait for the user to type anything.
It immediately reads a (number of) garbage characters (above ASCII
128) that the user never typed. Why?

--
Charlie Zender, su*****@uci.edu, [phone], Department of Earth
System Science, University of California, Irvine CA 92697-3100

[Jack Klein]

On Sat, 19 Jun 2004 15:46:18 -0700, Charlie Zender <ze****@uci.edu>
wrote in comp.lang.c:

Hi,

I have a program which takes the output filename argument from stdin.
Once the program knows the output filename, it tries to open it.
If the output file exists, the program asks the user to confirm
whether he really wants to overwrite the existing output file.
The problem is that the second read from stdin, to obtain the user
response whether to overwrite the existing output file, never
waits for the user's response. It's as if a bunch of characters
that are sitting in stdin get read before the user can respond.
I've tried strategically placing fflush(stdin) and fclose(stdin)
to fix the problem, but these fixes do not work.
I think there is something subtle about reading/flushing/closing
stdin that I do not understand. Any ideas?

Thanks,
Charlie

The logic looks like this:

User types...

echo "file_in" | my_program -o file_out

my_program uses fscanf to read stdin for the input filename---

while((cnv_nbr=fscanf(stdin,"%256s\n",bfr_in)) != EOF){
file_in=(char *)strdup(bfr_in);
}
Why are you using fscanf(stdin) instead of just plain scanf()? There
is absolutely no difference in functionality at all for the extra
typing?
my_program then opens file_in, does a lot of work (but does not
touch stdin again) until it eventually tries to write it to
file_out. If file_out already exists, user is queried and program
reads user response from stdin:

rcd=stat(file_out,&stat_sct);
if(rcd != -1){
fprintf(stdout,"File already exists---`o'verwrite (y/n)?");
usr_reply=(char)fgetc(stdin);
}

However, the fgetc() does not wait for the user to type anything.
It immediately reads a (number of) garbage characters (above ASCII
128) that the user never typed. Why?

This is a FAQ, specifically
http://www.eskimo.com/~scs/C-faq/q12.18.html.

A link to the entire FAQ is in my signature.

In addition, is it never a good idea to mix input types in a C
program, especially for live user input. It is generally a good idea
to use the *scanf() family at all in this case. Some claim that it is
possible, but it is most certainly extremely difficult to use these
functions safely and correctly on arbitrary input. With or without
scanf(), however, it makes things more difficult to mix line oriented
or formatted input with single character input functions like fgetc().

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

[CBFalconer]

Charlie Zender wrote:

I have a program which takes the output filename argument from stdin.
Once the program knows the output filename, it tries to open it.
If the output file exists, the program asks the user to confirm
whether he really wants to overwrite the existing output file.
The problem is that the second read from stdin, to obtain the user
response whether to overwrite the existing output file, never
waits for the user's response. It's as if a bunch of characters
that are sitting in stdin get read before the user can respond.
I've tried strategically placing fflush(stdin) and fclose(stdin)
to fix the problem, but these fixes do not work.
I think there is something subtle about reading/flushing/closing
stdin that I do not understand. Any ideas?
.... snip ...
my_program uses fscanf to read stdin for the input filename---

Don't use fscanf for interactive input. Use fgets. Check that
the last char in the input string is a '\n' (else there is more in
the input buffer) and change it to a '\0' for the filename.

Never use fflush on an input file. If you need to flush the stdin
input buffer (only in the 'more' case above) use a statement like:

int ch; /* declared in a suitable place */

while ((EOF != (ch = getchar())) && (ch != '\n')) continue;

--
fix (vb.): 1. to paper over, obscure, hide from public view; 2.
to work around, in a way that produces unintended consequences
that are worse than the original problem. Usage: "Windows ME
fixes many of the shortcomings of Windows 98 SE". - Hutchison

[CBFalconer]

Jack Klein wrote:

.... snip ...
In addition, is it never a good idea to mix input types in a C
program, especially for live user input. It is generally a good
idea to use the *scanf() family at all in this case. Some claim

I trust you omitted a 'not' in the previous sentence :-)
Alternatively, substitute 'bad' for 'good'.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

[Ralmin]

"CBFalconer" <cb********@yahoo.com> wrote:

Jack Klein wrote:

[snip]

It is generally a good idea to use the *scanf() family
at all in this case.

I trust you omitted a 'not' in the previous sentence :-)
Alternatively, substitute 'bad' for 'good'.

The phrase "at all" gives it away that Jack's intention was to negate the
word "good". Why do I seem to read so many people accidentally leaving out a
"not" or "n't" in sentences these days? Doesn't the sentence just look and
read totally wrong without it?

--
Simon.

[Dan Pop]

In <gn********************************@4ax.com> Jack Klein <ja*******@spamcop.net> writes:

In addition, is it never a good idea to mix input types in a C
program, especially for live user input. It is generally a good idea
to use the *scanf() family at all in this case. Some claim that it is
possible, but it is most certainly extremely difficult to use these
functions safely and correctly on arbitrary input.

The actual claim is that [f]scanf is the best way of getting a line of
input, for further processing by sscanf or whatever.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Dan Pop]

In <ad******************************@news.teranews.co m> "Ralmin" <ne**@ralminNOSPAM.cc> writes:

"CBFalconer" <cb********@yahoo.com> wrote:

Jack Klein wrote:

[snip]

> It is generally a good idea to use the *scanf() family
> at all in this case.

I trust you omitted a 'not' in the previous sentence :-)
Alternatively, substitute 'bad' for 'good'.

The phrase "at all" gives it away that Jack's intention was to negate the
word "good". Why do I seem to read so many people accidentally leaving out a
"not" or "n't" in sentences these days? Doesn't the sentence just look and
read totally wrong without it?

Because they write such sentences without (proof)reading them.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de