Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Runtime.exec on Win98: stdin, stdout with long DOS command line?

Reply
Thread Tools

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

 
 
Bernard
Guest
Posts: n/a
 
      12-27-2005
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/j...9-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'.


 
Reply With Quote
 
 
 
 
Raymond DeCampo
Guest
Posts: n/a
 
      01-01-2006
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/j...9-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.
 
Reply With Quote
 
 
 
 
Roedy Green
Guest
Posts: n/a
 
      01-02-2006
On Tue, 27 Dec 2005 15:55:25 +1300, Bernard <(E-Mail Removed)> 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.
 
Reply With Quote
 
Bernard
Guest
Posts: n/a
 
      01-03-2006
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 <(E-Mail Removed)> 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/j...9-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


 
Reply With Quote
 
Raymond DeCampo
Guest
Posts: n/a
 
      01-03-2006
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.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Having compilation error: no match for call to (const __gnu_cxx::hash<long long int>) (const long long int&) veryhotsausage C++ 1 07-04-2008 05:41 PM
Can I use winzip command in DOS command msmmgr Computer Support 8 10-05-2007 09:32 PM
beginner Q: Kernel#puts, STDOUT, $stdout relation Andreas S Ruby 3 12-09-2006 12:39 AM
Problems redirecting STDOUT (NOT sys.stdout) to a pipe. Elad Python 0 03-19-2006 01:30 PM
copy stdout fails with permission denied when stdout is redirected brian.mabry.edwards@gmail.com Perl Misc 2 12-07-2005 10:49 PM



Advertisments