Hi Raffaello,
Runtime.exec and ProcessBuilder have been a challenge from the
beginning, on one hand
to have a reasonably cross-platform way to invoke processes and on the
other to accommodate
the platform differences, mostly on Windows due to the various command
line parsing decoding of
Hi,
on Windows, the mechanism to launch a new program is for the parent to
call CreateProcess(). This function accepts, among others parameters, a
lpApplicationName string and a lpCommandLine string. There's a *single*
lpCommandLine that encodes all the arguments to pass to the new program.
Hello,
to overcome some of the problems with parsing and generating Windows
command lines, I implemented two classes [1] that attempt to provide a
more sophisticated solution. To be clear, they do not create processes
or launch programs. They only serve as a parser and an "escaper".
Hi Raffaello,
My mistake, the problem with empty args was fixed in 17 as well as some
of the problems with
escaping of double-quotes. The default legacy mode does not check for
unbalanced quotes
possible merging of arguments. The simplest case are for .exe
execution, in which the
argument
Hi Roger,
I'm trying the following (ugly) code on JDK 17/Win, where Args.exe does
nothing else than writing out its argv[], redirecting to a log file.
public static void main(String[] args) throws IOException,
InterruptedException {
String[] command = {
Hi Raffaello,
For .exe executables, one example is an empty string in the list of
arguments to ProcessBuilder.
The empty string is not visible in the generated command line. For
position sensitive commands, it appears the argument is dropped.
An argument in ProcessBuilder with mismatched
Hello,
if I understand correctly, the issue addressed here (on Windows) is how
to assemble a single command string from an array of argument strings to
pass to CreateProcess() in a way that the individual argument strings
can be fully recovered in the invoked program.
Similarly when the
A JEP to Improve safety of process launch by ProcessBuilder and
Runtime.exec on Windows[1].
Argument encoding errors have been problematic on Windows systems due to
improperly quoted command arguments.
The idea is to tighten up quoting and encoding of command line arguments.
Comments
