使用ProcessBuilder时Java不启动GZIP命令

Question

I definitely have GZIP installed on the boxes where I am trying this out. But when I run this in Java, I don't see the zipped file being created. The file I am dealing with is a really large file and I would rather not read it into memory. The following is the code, I have written for this purpose. My hunch is that it has something to do with Redirects.

try {
    ProcessBuilder builder = new ProcessBuilder("gzip", "-9", "<", filename, ">", zippedFilename);
    builder.start();
} catch (IOException e1) {
    // TODO Auto-generated catch block
    e1.printStackTrace();
}

Answer 1

First, it's worth noting that you can make this easier by avoiding an external process and using Java to do the compression:

Path input = Paths.get(filename);
Path zipped = Paths.get(zippedFilename);

try (OutputStream out = new GZIPOutputStream(
    new BufferedOutputStream(
        Files.newOutputStream(zipped)))) {

    Files.copy(input, out);
}

This has the additional advantage of being fully multi-platform. No need to require /usr/bin/gzip, no need to require Unix tools on Windows. It won't implement the -9 option, but I would check how much additional compression one actually gets with that option, and weigh whether it's worth having a less portable program.

For other commands (or if -9 is critically important), a ProcessBuilder command cannot do redirection of input and output with < and > , for the same reason a C program would not be able to accomplish redirection with a call like:

/* Does not work. */
execl("/usr/bin/gzip", "gzip", "-9", "<", filename, ">", zippedFilename, (char *)NULL);

When you run a command in a shell (like bash), the shell intercepts < and > , strips them and their subsequent arguments from the command, and invokes the actual program without them. Thus, typing this:

gzip -9 < filename > filename.gz

actually causes the shell to run gzip with just one argument: -9 . The shell then reads from filename and passes it to the standard input descriptor of the gzip program's process. Similarly, the shell captures the standard output from that same gzip program invocation, and writes it to filename.gz .

While this is going on, the gzip process has no idea where its input came from, or where its output is going. It is just reading from its own standard input and writing to its standard output.

When you invoke a program directly, you are bypassing the shell, so there is no special handling of < and > . This means that your current ProcessBuilder command is the equivalent of this Unix command:

gzip -9 '<' filename '>' filename.gz

which means you are invoking gzip with one option and four file arguments, which cause gzip to first look for a file whose name is one character long, a file literally named < , then write a compressed version of it to <.gz . It will then do the same with a file named filename , then a file named > , then a file named filename.gz .

So, as you can see, Unix commands know nothing about redirection. The < and > characters cannot be passed to them directly.

However, you can simulate redirection using ProcessBuilder:

ProcessBuilder builder = new ProcessBuilder("gzip", "-9");
builder.inheritIO();
builder.redirectInput(new File(filename));
builder.redirectOutput(new File(zippedFilename));

Process process = builder.start();

The call to inheritIO() will cause the external process's standard error (that is, any error messages) to appear on the Java program's standard error. Without that, you would have no indication of why the program failed. (It would do the same with standard input and standard output, if we hadn't redirected them.)