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

[Bernard]

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'.

 

[Raymond DeCampo]

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

 

[Roedy Green]

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.

 

[Bernard]

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

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

 

[Raymond DeCampo]

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