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



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

.



Relevant Pages

  • Re: Set App Priority
    ... string and then terminates" ... gives then parameters to use to modify the START command ... below) /F:OFF Disable file and directory name completion characters ... no special characters between the two quote characters, ...
    (microsoft.public.windowsxp.customize)
  • Re: how to calculate number of characters in argument?
    ... and would like to have available a command for calculating the ... the use of ASCII test within CJK text). ... to 0) for typesetting 9 half-width characters (which are I believe set ... It works by first stripping off everything before the decimal point, then feeding the remaining string of characters to a recursive macro that creates a \numexpr of the form: ...
    (comp.text.tex)
  • Re: Confusion about I/O Streams
    ... > I have to admit I've never fully understood the different Java I/O streams ... > so I've been reviewing them in the Java Tutorial. ... Characters are a higher-level abstraction than bytes. ... If you've got a String, you can get a bytefrom it using: ...
    (comp.lang.java.help)
  • Re: Using filenames with spaces in variable functions
    ... having the command interpreter not able to ... | filenames instead of persisting with the limitations of the string ... those characters were not legal in file names. ...
    (comp.os.msdos.4dos)
  • TIP #185: Null Handling
    ... nulls, and command modifications for manipulating them. ... Tcl deals with strings, the universal medium for representing data. ... is know and it is an empty string, but if a respondent forgets to give ...
    (comp.lang.tcl)