Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Runtime.exec(String[]) Doesn't Always Work, bBut Runtime.exec(String) Does

Reply
Thread Tools

Runtime.exec(String[]) Doesn't Always Work, bBut Runtime.exec(String) Does

 
 
Hal Vaughan
Guest
Posts: n/a
 
      05-22-2006
Gordon Beaton wrote:

> On Sun, 21 May 2006 15:49:27 -0400, Hal Vaughan wrote:
>> When I was specifying the program with only a String, every program
>> I would attempt would run. Now that I'm using String[], I have times
>> where I run one program and it works, then run the same program,
>> with the same arguments, a few seconds later, and waitFor() returns
>> immediately and I get no data from the ErrorStream or InputStream.
>>
>> I tried, as an experiment, to put quotation marks around the
>> filename in a string so it would look like this:
>>
>> "/usr/bin/myprogram" -myargument
>>
>> And that would not work -- the programs would not run at all.

>
> exec(String) simply tokenizes the command and invokes exec(String[]).
> So if exec(String) works but exec(String[]) doesn't, any problems with
> the latter are most likely due to your tokenization of the command
> line.
>
> exec(String[]) is, as you correctly observe, the right choice when
> your command contains *significant* whitespace, because the
> StringTokenizer used by exec(String) is not particularly smart.
>
> The rule is simple: each single component in the command line, i.e.
> the command name, an option flag, an argument, etc, is one String in
> the command array.
>
> Don't use any quotes or escape characters, because there is no shell
> to further interpret the command line. Any such characters will be
> treated literally by the system, so unless your program really is
> spelled with those characters it won't be found, or the arguments will
> be meaningless, etc.


Thanks for clearing that up. I had found out about the quotes the hard way,
but wasn't sure of the why behind it and didn't realize the String was
tokenized, but that also confirms my thought that spaces in the file name
would be trouble. Thanks for the details and explicit background on this.

>> So why is it that sometimes the program runs and I get input and
>> sometimes it doesn't? My best guess is that the program always runs,
>> but that there might be a timing issue that keeps me from reading
>> the streams quickly enough, but that doesn't sound likely.

>
> There should not be any timing issues. Data written to either of the
> streams stays there until you read it. And if you don't read it, the
> child will eventually hang waiting for you to do so, as you've already
> discovered. And you won't get EOF until you've emptied the streams and
> the child has exited (or closed the streams).
>
> I don't see BufferedReader.ready() or InputStream.available() in your
> code, but use of those could give the results you describe (avoid
> them).


That's what I've heard: avoid them like the plague because they aren't
reliable and are just messy.

> However if waitFor() returns, that is a string indication that your
> program has exited. What is returned by Process.exitValue()? What does
> your command line look like?
>
> /gordon


Usually the command is just running the file (could be almost any file) to
check for a version number, so it's not a long term situation. In most
cases, the command will be run with an argument like "--help" or "/help" to
get an output that will give me a unique string somewhere that identifies
the specific version. I also know the help info is usually printed to
STDERR, so I wasn't checking return codes from exitValue().

It seems that even after waitFor() returns and the process is done, the
buffers aren't completely "filled" with all the output yet. There's
another post about Thread.join() that I'm looking into.

Thanks for the help!

Hal

 
Reply With Quote
 
 
 
 
Gordon Beaton
Guest
Posts: n/a
 
      05-22-2006
On Mon, 22 May 2006 10:32:45 -0400, Hal Vaughan wrote:
> If the process is still running but hasn't printed anything to
> output for a while, what does readLine() return? An empty string
> instead of a null?


It's much simpler than that: readLine() *doesn't* return until there
*is* a line of text to return. At the end of the stream, it returns
null.

/gordon

--
[ do not email me copies of your followups ]
g o r d o n + n e w s @ b a l d e r 1 3 . s e
 
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
Trying to create a CSS box that is always is always the width of an image placed inside it (and no wider) Deryck HTML 4 06-22-2004 08:25 PM
Custom validator control does not always fire Dot net work ASP .Net 2 05-12-2004 06:40 AM
Global.asax does not always run in dev mode? =?Utf-8?B?QkI=?= ASP .Net 1 03-02-2004 06:31 AM
Why does Visual Studio always checkout files when looking Web User Control in design mode? Eric Mamet ASP .Net 0 01-30-2004 10:38 AM
TextChange event does not always fire Duwayne ASP .Net 1 08-20-2003 09:18 PM



Advertisments