Users who wish to shell out a Java program may be tempted to use Runtime.exec() , which yields a Process . They probably should use zt-exec instead. However, for those who think that using a separate library for something so “simple” is overkill, please read on.

General Notes

Java does not invoke a shell – Java uses execve() . This means that variables like ~ , %HOME% , and “ $JAVA_HOME ” will not be expanded, nor will you be able to use shell built-ins such as cd or while . However, Java can invoke a bash or cmd shell, which can then be fed input and output. For more information on shelling out to an actual shell, please see “Invoking A Shell.”

Invocation with Runtime

Runtime is the most accessible way to execute an external process. Processes are started with Runtime.exec(String) , Runtime.exec(String[]) , and variants based off of Runtime.exec(String) that accept an environment variable array and an optional directory. The only method that should be used from Runtime.exec() is the String[] variant. Each part of the String[] reflects a separate argument, with the 0th being the command to be run. For the functionality of an environment variable array and a directory, please see “Invocation with ProcessBuilder“.

No variant of Runtime.exec(String) should be used because Runtime.exec(String) splits the incoming string on spaces. This may not sound bad, as the shell also splits on spaces. Take the following:

sed 's/a b/c d/gi' "My Documents/foo.txt"

A shell would interpret this as ["sed", "s/a b/c d/gi", "My Documents/foo.txt"]

Runtime.exec(String) would interpret this as: ["sed", "'s/a", "b/c", "d/gi'", "\"My", "Documents/foo.txt\""]

Always use the Runtime.exec(String[]) variant.

After performing the invocation with Runtime , please see “Using Process“.

Invocation with Process Builder

ProcessBuilder takes a String... or a List<string> as its command argument. Each part of the String[] reflects a separate argument, with the 0th being the command to be run. In order to manipulate the environment, ProcessBuilder.environment() returns a mutable Map<String,String> of environment variables. This should be modified (it is not a read-only view, as pointed out by the summary javadoc). Setting the directory can be done with a .directory() call.

Other common operations are setting standard output to a file, with redirectOutput(File) , and merging standard input and standard output, with redirectErrorStream(true) . Starting the process can be done by calling .start() .

After performing this invocation, please see “Using Process“.

Invoking a Shell

This must be done by actually starting the shell process, and then the shell will interpret variables as normal. Done with ProcessBuilder, with the following algorithm:

List<String> parameters = new ArrayList<>(); if(System.getProperty("os.name").toLowerCase().contains("windows")) { parameters.add("cmd"); parameters.add("/C"); } else { parameters.add("/bin/bash"); parameters.add("-c"); }

This will start the OS-specific shell: cmd.exe on Windows, bash on other systems. Other shells may be substituted on linux by changing “ bash ” to the appropriate shell in the above. Those familiar with cmd may want to switch /C to /X – this is improper unless streams are redirected, with ProcessBuilder.inheritIO() .

Note that Windows’ PowerShell apparently introduces some difficulties. Apparently how it is invoked is different enough that these instructions aren’t enough.

Using Process

After a Process is obtained with either of the above methods, the process has been started and will run until its natural death. However, there are several common pitfalls.

You must cull the process with Process.waitFor() , even if you do not want all input and output from the process. Otherwise, the process will exist as a zombie until the parent process (the JVM) exits.

You do not have to read the output from the process, but if you read either stdout or stderr , you must read both. On some systems, if there is output in stderr , stdout is blocked until this output is consumed. This must be done in a multithreaded fashion if these streams are not joined.

If you want to terminate the process before finishing, you can call Process.destroy() – this sends the process-equivalent of the KILL signal to the process, not TERM , so use cautiously.

Putting it all together, the following is a sample of shelling out to an external process:

import java.io.IOException; import java.io.InputStream; import java.util.concurrent.Executors; import java.util.concurrent.ExecutorService; import java.util.concurrent.Future; import java.util.concurrent.Callable; public class Example { public static void main(String[] args) throws Exception { ExecutorService service = Executors.newSingleThreadExecutor(); Process p = Runtime.getRuntime().exec(new String[]{"echo", "Hello world"}); new Thread(new ErrorConsumer(p.getErrorStream())).start(); //java is the center of the universe Future output = service.submit(new OutputConsumer(p.getInputStream())); p.waitFor(); System.out.println(output.get()); } private static class ErrorConsumer implements Runnable { private final InputStream toDiscard; public ErrorConsumer(final InputStream toDiscard) { this.toDiscard = toDiscard; } @Override public void run() { byte[] buf = new byte[1024]; try { while (toDiscard.read(buf) != -1) ; } catch (IOException e) { e.printStackTrace(); } } } private static class OutputConsumer implements Callable</string><string> { private final InputStream toRead; public OutputConsumer(final InputStream toRead) { this.toRead = toRead; } @Override public String call() throws Exception { StringBuilder sb = new StringBuilder(); byte[] buf = new byte[1024]; int read; while ((read = toRead.read(buf)) != -1) { sb.append(new String(buf, 0, read)); } return sb.toString(); } } }

Editor’s note: this code may or may not work as expected. It runs, but may block on some operations – consider yourself warned, prepare to hit ^C , and use it as a point of emphasis on why you should be using zt-exec, shown immediately below…

Or, with zt-exec: