Reading stdin once confuses second stdin read

Discussion in 'C Programming' started by Charlie Zender, Jun 19, 2004.

  1. 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, , (949) 824-2987, Department of Earth
    System Science, University of California, Irvine CA 92697-3100
    Charlie Zender, Jun 19, 2004
    #1
    1. Advertising

  2. Charlie Zender

    Jack Klein Guest

    On Sat, 19 Jun 2004 15:46:18 -0700, Charlie Zender <>
    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/~ajo/docs/FAQ-acllc.html
    Jack Klein, Jun 20, 2004
    #2
    1. Advertising

  3. Charlie Zender

    CBFalconer Guest

    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, Jun 20, 2004
    #3
  4. Charlie Zender

    CBFalconer Guest

    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 () ()
    Available for consulting/temporary embedded and systems.
    <http://cbfalconer.home.att.net> USE worldnet address!
    CBFalconer, Jun 20, 2004
    #4
  5. Charlie Zender

    Ralmin Guest

    "CBFalconer" <> 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.
    Ralmin, Jun 20, 2004
    #5
  6. Charlie Zender

    Dan Pop Guest

    In <> "Ralmin" <> writes:

    >"CBFalconer" <> 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:
    Dan Pop, Jun 21, 2004
    #6
  7. Charlie Zender

    Dan Pop Guest

    In <> Jack Klein <> 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:
    Dan Pop, Jun 21, 2004
    #7
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Greg G
    Replies:
    2
    Views:
    2,002
    Greg G
    Jul 12, 2006
  2. Magnus Lyck?
    Replies:
    5
    Views:
    385
    Magnus Lyck?
    Dec 2, 2003
  3. Osiris
    Replies:
    0
    Views:
    272
    Osiris
    Jan 1, 2007
  4. Adam Funk
    Replies:
    4
    Views:
    417
    Adam Funk
    Dec 21, 2007
  5. Stefano Sabatini
    Replies:
    6
    Views:
    286
    Stefano Sabatini
    Jul 29, 2007
Loading...

Share This Page