Reading stdin once confuses second stdin read

C

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?
 
J

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

CBFalconer

Charlie said:
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;
 
C

CBFalconer

Jack said:
.... 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'.
 
R

Ralmin

CBFalconer said:
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?
 
D

Dan Pop

In said:
CBFalconer said:
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
 
D

Dan Pop

In said:
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
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,733
Messages
2,569,440
Members
44,830
Latest member
ZADIva7383

Latest Threads

Top