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?

 

[Jack Klein]

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().

 

[CBFalconer]

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;

 

[CBFalconer]

.... 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'.

 

[Ralmin]

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?

 

[Dan Pop]

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]

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