?s about Process Class

Discussion in 'Java' started by publius36, Jul 8, 2004.

  1. publius36

    publius36 Guest

    I have a DOS program I am trying to supply input to using Java.
    Reading from The Java Class Libraries, 2nd Ed. java.lang.Process class -
    the material presented seems to imply that I will be able to do
    this.

    The program most definately uses just stdio... (in) being the keyboard and
    (out) being the consol.

    Well I can't get it to work and being the presistant bugger that i am I have
    switch tactics so I can more up the learning curve.
    I have resorted to just trying to display the output of mem.exe.

    here is the source ::: test.java

    import java.io.*;
    import java.lang.*;

    public class test
    { public static void main(String[] args)
    {
    int ch;
    int status;

    try
    {
    Process process = Runtime.getRuntime().exec("mem.exe");
    InputStream in = process.getInputStream();
    BufferedInputStream buf = new BufferedInputStream(in);

    //try
    //{
    //status = process.waitFor();
    //}
    //catch (InterruptedException e) {status = -1;}

    try
    {
    while((ch = buf.read()) != -1)
    {
    System.out.print((char)ch);
    }

    }
    catch (IOException e) {System.out.println(e);}
    //in.close();
    //buf.close();
    //process.destroy();
    //Runtime.getRuntime().gc();
    //Runtime.getRuntime().exit(-1);
    //System.out.print('\n');
    }
    catch (IOException e) {System.out.println(e);}
    }
    }


    It works the first time I run the class file with java test.
    However, the next attempt hangs and requires a system restart inorder to get
    the code to display the results.

    The commented code in test.java are my attempts to do various things to
    clean up this issue of not displaying the results.

    Does anyone have a clue or suggestion...

    thanks,
    publius36
     
    publius36, Jul 8, 2004
    #1
    1. Advertising

  2. publius36

    Chris Smith Guest

    publius36 wrote:
    > Well I can't get it to work and being the presistant bugger that i am I have
    > switch tactics so I can more up the learning curve.
    > I have resorted to just trying to display the output of mem.exe.


    Okay. I have a number of comments. Many of them are not necessarily
    related to the specific problem you've got, but here they are anyway.

    First,

    > while((ch = buf.read()) != -1)
    > {
    > System.out.print((char)ch);
    > }


    BufferedInputStream reads bytes. System.out writes characters (it's a
    rather confused case, actually, but if you call its "print" method that
    it writes characters.) Bytes and characters are *not* the same thing.
    The right way to do this is to use an InputStreamReader to convert from
    bytes to characters.

    InputStream in = process.getInputStream();
    BufferedInputStream buf = new BufferedInputStream(in);
    InputStreamReader r = new InputStreamReader(buf);

    then

    while ((ch = r.read()) != -1)
    {
    System.out.print((char) ch);
    }

    then

    r.close();

    The way you've written your code only happens to work because your
    system default character encoding matches the byte-truncation of unicode
    for all characters that you read. As the system's default encoding
    changes, or as you start working with programs that output different
    characters such as accented or non-latin characters, the code will
    suddenly break. InputStreamReader solves that problem.

    > It works the first time I run the class file with java test.
    > However, the next attempt hangs and requires a system restart inorder to get
    > the code to display the results.


    Actually, it probably requires killing the runaway NTVDM process on
    Windows. There is a bug in modern 32-bit Windows operating systems
    running a 16-bit process in a way that doesn't attach it to a physical
    console, and this causes NTVDM to become confused. Since mem.exe is
    just a test program for you, the answer is to choose a different program
    to test with. Try "ipconfig.exe" instead.

    --
    www.designacourse.com
    The Easiest Way to Train Anyone... Anywhere.

    Chris Smith - Lead Software Developer/Technical Trainer
    MindIQ Corporation
     
    Chris Smith, Jul 8, 2004
    #2
    1. Advertising

  3. publius36

    publius36 Guest

    understood the things you stated, was very much aware of the need for using
    a reader
    i choose not to in test, trying to trouble shoot and much hair pulling
    later stated paring down the code...
    i know i'm not reading characters, hence

    int ch;

    i'm reading bytes from the BufferInputStream hence the type cast to (char)
    in the statement
    System.out.print((char)ch

    was trying to answer the question do i have the inputstream from the
    sub-process
    plugged into a buffer created by main that i can dump.

    it is the second observation :

    >
    > Actually, it probably requires killing the runaway NTVDM process on
    > Windows. There is a bug in modern 32-bit Windows operating systems
    > running a 16-bit process in a way that doesn't attach it to a physical
    > console, and this causes NTVDM to become confused. Since mem.exe is
    > just a test program for you, the answer is to choose a different program
    > to test with. Try "ipconfig.exe" instead.
    >

    it never ceases with billybob's MS OS's crap
    anyway, thanks for the help...
    since my program is definately a legacy 16-bit program
    i could be barking up a tree here.
    still i'll try using ipconfig.exe, just to learn a little bit more and do as
    you say
    get the readers and writers in place.

    thanks for your timely help
    sincerely, pub



    "Chris Smith" <> wrote in message
    news:...
    > publius36 wrote:
    > > Well I can't get it to work and being the presistant bugger that i am I

    have
    > > switch tactics so I can more up the learning curve.
    > > I have resorted to just trying to display the output of mem.exe.

    >
    > Okay. I have a number of comments. Many of them are not necessarily
    > related to the specific problem you've got, but here they are anyway.
    >
    > First,
    >
    > > while((ch = buf.read()) != -1)
    > > {
    > > System.out.print((char)ch);
    > > }

    >
    > BufferedInputStream reads bytes. System.out writes characters (it's a
    > rather confused case, actually, but if you call its "print" method that
    > it writes characters.) Bytes and characters are *not* the same thing.
    > The right way to do this is to use an InputStreamReader to convert from
    > bytes to characters.
    >
    > InputStream in = process.getInputStream();
    > BufferedInputStream buf = new BufferedInputStream(in);
    > InputStreamReader r = new InputStreamReader(buf);
    >
    > then
    >
    > while ((ch = r.read()) != -1)
    > {
    > System.out.print((char) ch);
    > }
    >
    > then
    >
    > r.close();
    >
    > The way you've written your code only happens to work because your
    > system default character encoding matches the byte-truncation of unicode
    > for all characters that you read. As the system's default encoding
    > changes, or as you start working with programs that output different
    > characters such as accented or non-latin characters, the code will
    > suddenly break. InputStreamReader solves that problem.
    >
    > > It works the first time I run the class file with java test.
    > > However, the next attempt hangs and requires a system restart inorder to

    get
    > > the code to display the results.

    >
    > Actually, it probably requires killing the runaway NTVDM process on
    > Windows. There is a bug in modern 32-bit Windows operating systems
    > running a 16-bit process in a way that doesn't attach it to a physical
    > console, and this causes NTVDM to become confused. Since mem.exe is
    > just a test program for you, the answer is to choose a different program
    > to test with. Try "ipconfig.exe" instead.
    >
    > --
    > www.designacourse.com
    > The Easiest Way to Train Anyone... Anywhere.
    >
    > Chris Smith - Lead Software Developer/Technical Trainer
    > MindIQ Corporation
     
    publius36, Jul 8, 2004
    #3
  4. publius36

    publius36 Guest

    ipconfig is work well for test purposes..

    however the code frag you gave...

    > InputStream in = process.getInputStream();
    > BufferedInputStream buf = new BufferedInputStream(in);
    > InputStreamReader r = new InputStreamReader(buf);


    won't work : syntax ---> public InputStreamReader(InputStream in)
    you are supplying a BufferedInputStream object and not the required
    InputStream object

    the correct code frag should be :

    InputStream in = nhProcess.getInputStream();
    InputStreamReader r = new InputStreamReader(in);
    BufferedReader buf = new BufferedReader(r);

    to achieve what you intended.
    even though the syntax for BufferedReader is
    public BufferedReader(Reader obj)
    I think it works because the Reader object is the superclass
    of all readers, and why it can handle the InputStreamReader object.





    "Chris Smith" <> wrote in message
    news:...
    > publius36 wrote:
    > > Well I can't get it to work and being the presistant bugger that i am I

    have
    > > switch tactics so I can more up the learning curve.
    > > I have resorted to just trying to display the output of mem.exe.

    >
    > Okay. I have a number of comments. Many of them are not necessarily
    > related to the specific problem you've got, but here they are anyway.
    >
    > First,
    >
    > > while((ch = buf.read()) != -1)
    > > {
    > > System.out.print((char)ch);
    > > }

    >
    > BufferedInputStream reads bytes. System.out writes characters (it's a
    > rather confused case, actually, but if you call its "print" method that
    > it writes characters.) Bytes and characters are *not* the same thing.
    > The right way to do this is to use an InputStreamReader to convert from
    > bytes to characters.
    >
    > InputStream in = process.getInputStream();
    > BufferedInputStream buf = new BufferedInputStream(in);
    > InputStreamReader r = new InputStreamReader(buf);
    >
    > then
    >
    > while ((ch = r.read()) != -1)
    > {
    > System.out.print((char) ch);
    > }
    >
    > then
    >
    > r.close();
    >
    > The way you've written your code only happens to work because your
    > system default character encoding matches the byte-truncation of unicode
    > for all characters that you read. As the system's default encoding
    > changes, or as you start working with programs that output different
    > characters such as accented or non-latin characters, the code will
    > suddenly break. InputStreamReader solves that problem.
    >
    > > It works the first time I run the class file with java test.
    > > However, the next attempt hangs and requires a system restart inorder to

    get
    > > the code to display the results.

    >
    > Actually, it probably requires killing the runaway NTVDM process on
    > Windows. There is a bug in modern 32-bit Windows operating systems
    > running a 16-bit process in a way that doesn't attach it to a physical
    > console, and this causes NTVDM to become confused. Since mem.exe is
    > just a test program for you, the answer is to choose a different program
    > to test with. Try "ipconfig.exe" instead.
    >
    > --
    > www.designacourse.com
    > The Easiest Way to Train Anyone... Anywhere.
    >
    > Chris Smith - Lead Software Developer/Technical Trainer
    > MindIQ Corporation
     
    publius36, Jul 8, 2004
    #4
  5. publius36 wrote:

    [Chris Smith wrote:]
    >> InputStream in = process.getInputStream();
    >> BufferedInputStream buf = new BufferedInputStream(in);
    >> InputStreamReader r = new InputStreamReader(buf);

    >
    >
    > won't work : syntax ---> public InputStreamReader(InputStream in)
    > you are supplying a BufferedInputStream object and not the required
    > InputStream object


    A BufferedInputStream *is* an InputStream. Chris' code fragment will
    work just fine.


    John Bollinger
     
    John C. Bollinger, Jul 8, 2004
    #5
    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. Rithesh Pai
    Replies:
    1
    Views:
    5,600
  2. E11
    Replies:
    1
    Views:
    4,788
    Thomas Weidenfeller
    Oct 12, 2005
  3. christopher diggins
    Replies:
    16
    Views:
    756
    Pete Becker
    May 4, 2005
  4. Earl Eiland
    Replies:
    0
    Views:
    323
    Earl Eiland
    May 10, 2005
  5. Joseph Turian
    Replies:
    5
    Views:
    596
Loading...

Share This Page