Runtime.exec on Win98: stdin, stdout with long DOS command line?

Discussion in 'Java' started by Bernard, Dec 27, 2005.

  1. Bernard

    Bernard Guest

    Hi all Java Gurus

    I can't get Runtime.exec() to work with DOS commands longer than 127
    characters (the command.com limit) under Win98 2nd edition.

    I use a workaround, start.exe to execute my DOS command. This executes
    command lines successfully that are longer than 127 characters.

    However, with start.exe, stdin and stdout of my executed command do
    not appear to be accessible at all from the Java Process object.

    Whatever I write to Process.getOutputStream() gets ignored, typically
    with the effect of the DOS program hanging while it waits for input.

    If I don't need to write to Process.getOutputStream(), then still
    whatever I read from Process.getInputStream() is empty.

    This is all Win9x specific, because on NT, Win2000 and XP systems,
    there is no such command line length limitation, and therefore there
    is no need for the start.exe workaround.

    I use separate threads for reading stdin and stderr much like as
    documented at
    http://www.javaworld.com/javaworld/jw-12-2000/jw-1229-traps_p.html
    so I am not a beginner in the use of Runtime.exec().

    It appears to me that my issue is not yet documented anywhere on the
    web. It would be nice to have a simple solution. As long as there is
    none, my recommendation would be to avoid Runtime.exec on Win9*
    platforms wherever stdin, stdout and stderr must be used, because it
    would be dangerous to ignore the 127 character command line length
    limit of command.com.

    Any suggestions are highly appreciated.

    Bernard

    Note: I use the GNUPG encryption program that has a mode that uses
    stdin and stdout for data:
    start /m /w C:\g\gpg.exe --batch --homedir \tmp\sender --always-trust
    --armor --encrypt --recipient 1AE899CCDAD5F9A984A9747708378A798F388655
    C:\WINDOWS\TEMP\tmp3831.tmp
    exitCode = 0

    The above example does not even use stdin, it uses a file as input. If
    you want to use stdin, then remove the parameter for the input file
    e.g. 'C:\WINDOWS\TEMP\tmp3831.tmp'.
     
    Bernard, Dec 27, 2005
    #1
    1. Advertising

  2. Bernard wrote:
    > Hi all Java Gurus
    >
    > I can't get Runtime.exec() to work with DOS commands longer than 127
    > characters (the command.com limit) under Win98 2nd edition.
    >
    > I use a workaround, start.exe to execute my DOS command. This executes
    > command lines successfully that are longer than 127 characters.
    >
    > However, with start.exe, stdin and stdout of my executed command do
    > not appear to be accessible at all from the Java Process object.
    >
    > Whatever I write to Process.getOutputStream() gets ignored, typically
    > with the effect of the DOS program hanging while it waits for input.
    >
    > If I don't need to write to Process.getOutputStream(), then still
    > whatever I read from Process.getInputStream() is empty.
    >
    > This is all Win9x specific, because on NT, Win2000 and XP systems,
    > there is no such command line length limitation, and therefore there
    > is no need for the start.exe workaround.
    >
    > I use separate threads for reading stdin and stderr much like as
    > documented at
    > http://www.javaworld.com/javaworld/jw-12-2000/jw-1229-traps_p.html
    > so I am not a beginner in the use of Runtime.exec().
    >
    > It appears to me that my issue is not yet documented anywhere on the
    > web. It would be nice to have a simple solution. As long as there is
    > none, my recommendation would be to avoid Runtime.exec on Win9*
    > platforms wherever stdin, stdout and stderr must be used, because it
    > would be dangerous to ignore the 127 character command line length
    > limit of command.com.
    >
    > Any suggestions are highly appreciated.
    >


    1) You could try writing out your command to a temporary BAT file, and
    then simply execute the BAT file via Runtime.exec(). I think that the
    streams will be preserved in that case, but you may need to experiment.

    2) Have you tried using Runtime.exec(String[]) (instead of
    Runtime.exec(String))?

    HTH,
    Ray

    --
    XML is the programmer's duct tape.
     
    Raymond DeCampo, Jan 1, 2006
    #2
    1. Advertising

  3. Bernard

    Roedy Green Guest

    On Tue, 27 Dec 2005 15:55:25 +1300, Bernard <> wrote,
    quoted or indirectly quoted someone who said :

    >would be dangerous to ignore the 127 character command line length
    >limit of command.com.


    don't use command.com. Try 4DOS which has a slightly longer limit,
    IIRC. See http://mindprod.com/jgloss/fordos.html

    DOS itself has uses a fixed size, fixed format command block to
    communicate with *.com files. There is no room to expand the command
    line. What you can do if you have control over the DOS app is put data
    into set environment variables.

    --
    Canadian Mind Products, Roedy Green.
    http://mindprod.com Java custom programming, consulting and coaching.
     
    Roedy Green, Jan 2, 2006
    #3
  4. Bernard

    Bernard Guest

    Raymond and Roedy,

    Thanks for your suggestions.

    Runtime.exec(String[]) (instead of Runtime.exec(String)) as you
    suggested removes the command.com 127 char limit!

    I had already used it but I did not realise that my 127 char
    limitation was from prior experience with Runtime.exec(String)) which
    cannot be applied here.

    Still the process hangs even without start.exe but that might be
    caused by gpg.exe. It almost appears that it cannot detect the closing
    of stdin as in the command

    gpg.exe --batch --homedir \tmp\sender --always-trust
    --armor --encrypt --recipient 1AE899CCDAD5F9A984A9747708378A798F388655

    Regards

    Bernard


    Raymond DeCampo <> wrote:

    >Bernard wrote:
    >> Hi all Java Gurus
    >>
    >> I can't get Runtime.exec() to work with DOS commands longer than 127
    >> characters (the command.com limit) under Win98 2nd edition.
    >>
    >> I use a workaround, start.exe to execute my DOS command. This executes
    >> command lines successfully that are longer than 127 characters.
    >>
    >> However, with start.exe, stdin and stdout of my executed command do
    >> not appear to be accessible at all from the Java Process object.
    >>
    >> Whatever I write to Process.getOutputStream() gets ignored, typically
    >> with the effect of the DOS program hanging while it waits for input.
    >>
    >> If I don't need to write to Process.getOutputStream(), then still
    >> whatever I read from Process.getInputStream() is empty.
    >>
    >> This is all Win9x specific, because on NT, Win2000 and XP systems,
    >> there is no such command line length limitation, and therefore there
    >> is no need for the start.exe workaround.
    >>
    >> I use separate threads for reading stdin and stderr much like as
    >> documented at
    >> http://www.javaworld.com/javaworld/jw-12-2000/jw-1229-traps_p.html
    >> so I am not a beginner in the use of Runtime.exec().
    >>
    >> It appears to me that my issue is not yet documented anywhere on the
    >> web. It would be nice to have a simple solution. As long as there is
    >> none, my recommendation would be to avoid Runtime.exec on Win9*
    >> platforms wherever stdin, stdout and stderr must be used, because it
    >> would be dangerous to ignore the 127 character command line length
    >> limit of command.com.
    >>
    >> Any suggestions are highly appreciated.
    >>

    >
    >1) You could try writing out your command to a temporary BAT file, and
    >then simply execute the BAT file via Runtime.exec(). I think that the
    >streams will be preserved in that case, but you may need to experiment.
    >
    >2) Have you tried using Runtime.exec(String[]) (instead of
    >Runtime.exec(String))?
    >
    >HTH,
    >Ray
     
    Bernard, Jan 3, 2006
    #4
  5. Bernard wrote:
    > Raymond and Roedy,
    >
    > Thanks for your suggestions.
    >
    > Runtime.exec(String[]) (instead of Runtime.exec(String)) as you
    > suggested removes the command.com 127 char limit!
    >
    > I had already used it but I did not realise that my 127 char
    > limitation was from prior experience with Runtime.exec(String)) which
    > cannot be applied here.
    >
    > Still the process hangs even without start.exe but that might be
    > caused by gpg.exe. It almost appears that it cannot detect the closing
    > of stdin as in the command
    >
    > gpg.exe --batch --homedir \tmp\sender --always-trust
    > --armor --encrypt --recipient 1AE899CCDAD5F9A984A9747708378A798F388655
    >


    Have you explicitly closed the input stream to gpg.exe and are you
    reading from both the stdout and stderr streams?

    HTH,
    Ray

    --
    XML is the programmer's duct tape.
     
    Raymond DeCampo, Jan 3, 2006
    #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. Guest

    exec with stdin stdout

    Guest, Sep 6, 2005, in forum: Java
    Replies:
    4
    Views:
    1,171
    Roedy Green
    Sep 6, 2005
  2. Paul Gessos

    exec with stdin stdout

    Paul Gessos, Sep 6, 2005, in forum: Java
    Replies:
    3
    Views:
    589
    Andrew Thompson
    Sep 6, 2005
  3. Hal Vaughan
    Replies:
    11
    Views:
    1,201
    Gordon Beaton
    May 22, 2006
  4. Replies:
    4
    Views:
    3,077
    Robert Mark Bram
    Oct 31, 2006
  5. Replies:
    0
    Views:
    1,213
Loading...

Share This Page