Weird I/O bug

Discussion in 'Java' started by Spencer Rugaber, Sep 6, 2008.

  1. I ran across an interesting bug, which I have isolated to the
    following:

    /* 1*/ import java.io.*;
    /* 2*/ public class WordCount {
    /* 3*/ public static void main (String[] args) {
    /* 4*/ InputStreamReader tr = new InputStreamReader(System.in);
    /* 5*/ try {
    /* 6*/ tr.read(); /* Input intentionally ignored */
    /* 7*/ } catch (Exception e) {
    /* 8*/ System.exit(-1);
    /* 9*/ }
    /*10*/ System.out.println(0);
    /*11*/ System.exit(0);
    /*12*/ }
    /*13*/ }

    When run with input consisting of an empty file from standard in,
    the output is a line consisting only of "0D".

    If input is from a file, rather than the command line, the program
    works, printing only "0". If lines 4-9 are removed, the program
    works.

    The problems, occurs in Java 1.3, 1.4, 1.5. It occurs on Linux,
    Solaris and Windows systems.

    The only thoughts I have are 1) that somehow stdin and stdout both
    being the terminal confuses things, or 2) somehow, conversion between
    bytes and ints is a problem.

    I can't be the first person to notice this problem. All suggestions
    appreciated.

    Thanks.

    Spencer
    --

    Spencer
    -------

    Spencer Rugaber
    2406 Klaus Advanced Computing Building
    College of Computing, Georgia Tech, Atlanta GA 30332-0280
    Internet:
    Phone: (404) 894-8450 Fax: (404) 894-9442
    WWW: http://www.cc.gatech.edu/fac/Spencer.Rugaber
    Spencer Rugaber, Sep 6, 2008
    #1
    1. Advertising

  2. Spencer Rugaber

    Mark Space Guest

    Spencer Rugaber wrote:

    > When run with input consisting of an empty file from standard in,
    > the output is a line consisting only of "0D".
    >
    > If input is from a file, rather than the command line, the program
    > works, printing only "0". If lines 4-9 are removed, the program
    > works.


    For me it simply prints 0 both times, which I think is correct. What
    output where you expecting?
    Mark Space, Sep 6, 2008
    #2
    1. Advertising

  3. Spencer Rugaber

    Roedy Green Guest

    On 5 Sep 2008 21:44:27 -0400, (Spencer Rugaber)
    wrote, quoted or indirectly quoted someone who said :

    >When run with input consisting of an empty file from standard in,
    >the output is a line consisting only of "0D".


    that is as invalid file. It shoulds be either 0D 0A or 0A.

    The problem is similar to having only half of a multibyte unicode
    encoding.

    There needs to be an InvalidDataException.
    --

    Roedy Green Canadian Mind Products
    The Java Glossary
    http://mindprod.com
    Roedy Green, Sep 6, 2008
    #3
  4. Spencer Rugaber

    Arne Vajhøj Guest

    Roedy Green wrote:
    > On 5 Sep 2008 21:44:27 -0400, (Spencer Rugaber)
    > wrote, quoted or indirectly quoted someone who said :
    >> When run with input consisting of an empty file from standard in,
    >> the output is a line consisting only of "0D".

    >
    > that is as invalid file. It shoulds be either 0D 0A or 0A.
    >
    > The problem is similar to having only half of a multibyte unicode
    > encoding.


    Not at all.

    CR is a valid line terminator in older versions of Mac OS.

    0x0D is valid file content not being a line terminator with
    counted record formats.

    Arne
    Arne Vajhøj, Sep 6, 2008
    #4
  5. Spencer Rugaber

    Roedy Green Guest

    On 5 Sep 2008 21:44:27 -0400, (Spencer Rugaber)
    wrote, quoted or indirectly quoted someone who said :

    >When run with input consisting of an empty file from standard in,
    >the output is a line consisting only of "0D".


    i presume you mean one 8-bit hex char 0d, not two chars 0 D
    --

    Roedy Green Canadian Mind Products
    The Java Glossary
    http://mindprod.com
    Roedy Green, Sep 6, 2008
    #5
  6. In article <g9sn9r$>,
    (Spencer Rugaber) wrote:

    [...]
    > When run with input consisting of an empty file from standard in,
    > the output is a line consisting only of "0D".
    >
    > If input is from a file, rather than the command line, the program
    > works, printing only "0". If lines 4-9 are removed, the program
    > works.

    [...]

    $ java -version
    java version "1.5.0_13"
    ....
    $ touch temp.txt
    $ java WordCount < temp.txt
    0
    $ java WordCount
    0D

    The last result required control-D (EOT) to terminate input. Is that
    what you're seeing?

    --
    John B. Matthews
    trashgod at gmail dot com
    home dot woh dot rr dot com slash jbmatthews
    John B. Matthews, Sep 6, 2008
    #6
  7. Spencer Rugaber

    Tom Anderson Guest

    On Sat, 6 Sep 2008, John B. Matthews wrote:

    > In article <g9sn9r$>,
    > (Spencer Rugaber) wrote:
    >
    > [...]
    >> When run with input consisting of an empty file from standard in,
    >> the output is a line consisting only of "0D".
    >>
    >> If input is from a file, rather than the command line, the program
    >> works, printing only "0". If lines 4-9 are removed, the program
    >> works.

    > [...]
    >
    > $ java -version
    > java version "1.5.0_13"
    > ...
    > $ touch temp.txt
    > $ java WordCount < temp.txt
    > 0
    > $ java WordCount
    > 0D
    >
    > The last result required control-D (EOT) to terminate input. Is that
    > what you're seeing?


    This is what i assumed he meant - i think this discussion of hex values is
    off-beam. And i get the same result on MacOS X, FWIW.

    I think what this is is the shell (or possibly the terminal driver, or
    maybe even the java binary) echoing "^D" to the screen when you type that
    escape sequence - that's standard behaviour. When the app then prints that
    0, it overwrites the ^, and you see 0D.

    If you modify the program to print the empty string, then what you see on
    screen is "^D". If you modify it to print 99, you just see the 99. If you
    modify it not to call print at all, then you very briefly see ^D, but this
    is then overwritten by the prompt that appears after the program
    terminates (or at least, i do - your console may be faster than mine!). If
    you run the unmodified program, but redirect the output to a file, it just
    contains 0. All this fits with the explanation i give above.

    tom

    --
    Ed editor textorum probatissimus est -- Cicero, De officiis IV.7
    Tom Anderson, Sep 6, 2008
    #7
  8. In article <>,
    Roedy Green <> wrote:
    >>When run with input consisting of an empty file from standard in,
    >>the output is a line consisting only of "0D".

    >
    >i presume you mean one 8-bit hex char 0d, not two chars 0 D


    What I see on the screen is a line by itself containing only the
    characters 0 and D, adjacent to each other. This is not what I
    expected to see, which was a 0 by itself on a line.

    Spencer
    --

    Spencer
    -------

    Spencer Rugaber
    2406 Klaus Advanced Computing Building
    College of Computing, Georgia Tech, Atlanta GA 30332-0280
    Internet:
    Phone: (404) 894-8450 Fax: (404) 894-9442
    WWW: http://www.cc.gatech.edu/fac/Spencer.Rugaber
    Spencer Rugaber, Sep 6, 2008
    #8
  9. In article <>,
    John B. Matthews <> wrote:
    >The last result required control-D (EOT) to terminate input. Is that
    >what you're seeing?


    Exactly.

    Spencer
    --

    Spencer
    -------

    Spencer Rugaber
    2406 Klaus Advanced Computing Building
    College of Computing, Georgia Tech, Atlanta GA 30332-0280
    Internet:
    Phone: (404) 894-8450 Fax: (404) 894-9442
    WWW: http://www.cc.gatech.edu/fac/Spencer.Rugaber
    Spencer Rugaber, Sep 6, 2008
    #9
  10. In article <>,
    Tom Anderson <> wrote:
    >I think what this is is the shell (or possibly the terminal driver, or
    >maybe even the java binary) echoing "^D" to the screen when you type that
    >escape sequence - that's standard behaviour. When the app then prints that
    >0, it overwrites the ^, and you see 0D.


    >If you modify the program to print the empty string, then what you see on
    >screen is "^D". If you modify it to print 99, you just see the 99. If you
    >modify it not to call print at all, then you very briefly see ^D, but this
    >is then overwritten by the prompt that appears after the program
    >terminates (or at least, i do - your console may be faster than mine!). If
    >you run the unmodified program, but redirect the output to a file, it just
    >contains 0. All this fits with the explanation i give above.


    This sounds reasonable, but why don't I see the ^D when I talk to the
    shell directly, as with the command "cat" (by itself taking input from
    the command line). If that input is only ^D, then nothing is echoed.

    So Java's behavior still seems weird to me. Is this what I should
    expect from Java? I could find no justification for it in the API
    description.

    Thanks.

    Spencer
    --

    Spencer
    -------

    Spencer Rugaber
    2406 Klaus Advanced Computing Building
    College of Computing, Georgia Tech, Atlanta GA 30332-0280
    Internet:
    Phone: (404) 894-8450 Fax: (404) 894-9442
    WWW: http://www.cc.gatech.edu/fac/Spencer.Rugaber
    Spencer Rugaber, Sep 6, 2008
    #10
  11. Spencer Rugaber

    Tom Anderson Guest

    On Sat, 6 Sep 2008, Spencer Rugaber wrote:

    > In article <>,
    > Tom Anderson <> wrote:
    >
    >> I think what this is is the shell (or possibly the terminal driver, or
    >> maybe even the java binary) echoing "^D" to the screen when you type that
    >> escape sequence - that's standard behaviour. When the app then prints that
    >> 0, it overwrites the ^, and you see 0D.
    >>
    >> If you modify the program to print the empty string, then what you see on
    >> screen is "^D". If you modify it to print 99, you just see the 99. If you
    >> modify it not to call print at all, then you very briefly see ^D, but this
    >> is then overwritten by the prompt that appears after the program
    >> terminates (or at least, i do - your console may be faster than mine!). If
    >> you run the unmodified program, but redirect the output to a file, it just
    >> contains 0. All this fits with the explanation i give above.

    >
    > This sounds reasonable, but why don't I see the ^D when I talk to the
    > shell directly, as with the command "cat" (by itself taking input from
    > the command line). If that input is only ^D, then nothing is echoed.
    >
    > So Java's behavior still seems weird to me. Is this what I should
    > expect from Java? I could find no justification for it in the API
    > description.


    Got a C compiler? Try this:

    #include <stdio.h>
    int main(int argc, char **argv) {
    char buf[100] ;
    gets(buf) ;
    printf("%i\n", 0) ;
    return 0 ;
    }

    tom

    --
    Ed editor textorum probatissimus est -- Cicero, De officiis IV.7
    Tom Anderson, Sep 6, 2008
    #11
  12. In article <>,
    Tom Anderson <> wrote:

    > On Sat, 6 Sep 2008, Spencer Rugaber wrote:
    >
    > > In article <>,
    > > Tom Anderson <> wrote:
    > >
    > >> I think what this is is the shell (or possibly the terminal driver, or
    > >> maybe even the java binary) echoing "^D" to the screen when you type that
    > >> escape sequence - that's standard behaviour. When the app then prints that
    > >> 0, it overwrites the ^, and you see 0D.
    > >>
    > >> If you modify the program to print the empty string, then what you see on
    > >> screen is "^D". If you modify it to print 99, you just see the 99. If you
    > >> modify it not to call print at all, then you very briefly see ^D, but this
    > >> is then overwritten by the prompt that appears after the program
    > >> terminates (or at least, i do - your console may be faster than mine!). If
    > >> you run the unmodified program, but redirect the output to a file, it just
    > >> contains 0. All this fits with the explanation i give above.


    I agree. If I modify it to print " ", I get a fleeting "^" followed by "
    D". The shell also echoes other control characters this way. Sorry if I
    overlooked it, but I missed your post above in this thread:

    <http://groups.google.com/group/comp.lang.java.programmer/browse_frm/thre
    ad/dee2331e25a0c47a/e14f72c577449842?hl=en&lnk=st&q=#e14f72c577449842>

    > > This sounds reasonable, but why don't I see the ^D when I talk to the
    > > shell directly, as with the command "cat" (by itself taking input from
    > > the command line). If that input is only ^D, then nothing is echoed.


    If cat echoes anything, it swallows the first ^D and the shell backs
    over a second one.

    > > So Java's behavior still seems weird to me. Is this what I should
    > > expect from Java? I could find no justification for it in the API
    > > description.

    >
    > Got a C compiler? Try this:
    >
    > #include <stdio.h>
    > int main(int argc, char **argv) {
    > char buf[100] ;
    > gets(buf) ;
    > printf("%i\n", 0) ;
    > return 0 ;
    > }
    >
    > tom


    FWIW, I get the same result in C on Mac OS, too.

    --
    John B. Matthews
    trashgod at gmail dot com
    home dot woh dot rr dot com slash jbmatthews
    John B. Matthews, Sep 6, 2008
    #12
  13. Spencer Rugaber wrote:
    > In article <>,
    > Tom Anderson <> wrote:
    >> I think what this is is the shell (or possibly the terminal driver, or
    >> maybe even the java binary) echoing "^D" to the screen when you type that
    >> escape sequence - that's standard behaviour. When the app then prints that
    >> 0, it overwrites the ^, and you see 0D.

    >
    >> If you modify the program to print the empty string, then what you see on
    >> screen is "^D". If you modify it to print 99, you just see the 99. If you
    >> modify it not to call print at all, then you very briefly see ^D, but this
    >> is then overwritten by the prompt that appears after the program
    >> terminates (or at least, i do - your console may be faster than mine!). If
    >> you run the unmodified program, but redirect the output to a file, it just
    >> contains 0. All this fits with the explanation i give above.

    >
    > This sounds reasonable, but why don't I see the ^D when I talk to the
    > shell directly, as with the command "cat" (by itself taking input from
    > the command line). If that input is only ^D, then nothing is echoed.
    >
    > So Java's behavior still seems weird to me. Is this what I should
    > expect from Java? I could find no justification for it in the API
    > description.
    >


    From what Tom and others have said, it isn't Java , it is your shell
    which is responsible for the "D" which you are seeing.

    --
    RGB
    RedGrittyBrick, Sep 7, 2008
    #13
    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. dorayme
    Replies:
    1
    Views:
    618
    richard
    Jan 21, 2011
  2. richard
    Replies:
    0
    Views:
    578
    richard
    Jan 21, 2011
  3. richard
    Replies:
    0
    Views:
    613
    richard
    Jan 21, 2011
  4. Beauregard T. Shagnasty

    Re: A Weird Appearance for a Weird Site

    Beauregard T. Shagnasty, Jan 21, 2011, in forum: HTML
    Replies:
    1
    Views:
    436
    Captain Paralytic
    Jan 21, 2011
  5. David Segall
    Replies:
    0
    Views:
    628
    David Segall
    Jan 22, 2011
Loading...

Share This Page