If you happen to have command execution via Java's Runtime.exec on a Unix system, you may already have noticed that it doesn't behave like a normal shell. Although simple commands like ls -al, uname -a, or netstat -ant work fine, more complex commands and especially commands with indispensable features like pipes, redirections, quoting, or expansions do not work at all.
Well, the reason for that is that the command passed to Runtime.exec is not executed by a shell. Instead, if you dig down though the Java source code, you'll end up in the UNIXProcess class, which reveals that calling Runtime.exec results in a fork and exec call on Unix platforms.
Nonetheless, I'll show you a way to still get commands executed in a proper shell.
For testing, we'll use this Java example:
We call this class as shown below with single quotes around the command line to ensure that our shell passes the command line argument to Java as is:
$ java Exec 'command arg1 arg2 ...'
Your first thought on a solution to this might be: "Ok, I'll just use sh -c command to execute command in the shell."
That is correct, but here is the catch: Since only the first argument following -c is interpreted as shell command, the whole shell command must be passed as a single argument. And if you take a closer look at how the string passed to Runtime.exec is processed, you'll see that Java uses a StringTokenizer that splits the command at any white-space character.
If you are thinking of quoting the command parameter string like uname -a as follows:
$ java Exec 'sh -c "uname -a"'
this won't work. Remember: We're not in a shell yet, and Runtime.exec does only take white-spaces as argument separators into account.
So, what is the other option that we have?
The key is in the sh -c command, but we won't execute the command directly but build a command that itself spawns another shell that then executes our command. Though it sounds complicated, we'll derive it step by step.
How it works
The secret key to this is the special parameter @, which expands to the positional parameters when referenced with $@, starting from parameter one:
$ java Exec 'sh -c $@'
But how do we pass the actual command? Well, if the shell is invoked with -c, any remaining arguments after the command argument are assigned to the positional parameters, starting with $0. So when $@ is expanded by the shell with the following invocation:
$ java Exec 'sh -c $@ 0 1 2 3 4 5'
It results in 1 2 3 4 5. The 0-th parameter does not appear in the expansion result as it, by convention, should be the file name associated with the file being executed. We can see the result by adding a echo in place of the $1 parameter:
$ java Exec 'sh -c $@ 0 echo 1 2 3 4 5'
Here the shell first expands $@ to echo 1 2 3 4 5 and then executes it.
But this is still not better than the simple sh -c command, as we still have no support of pipes, redirections, quoting or expansion.
The reason for this is that the $@ expansion does not result in a restart of the command interpretation.
The solution to a fully functional shell is sh's ability to allow the commands to be passed via standard input. So, if we use another echo to echo our command and pipe it to sh, we'll get our command executed by sh entirely:
$ java Exec 'sh -c $@|sh . echo command'
Now we have all shell features available!
The only thing to remember is that any white-space sequences vital in your command must be encoded somehow as otherwise it would be eaten by Java's StringTokenizer, e.g.:
$ java Exec 'sh -c $@|sh . echo /bin/echo -e "tab\trequired"'
And to anyone who is interested in what the process tree looks like:
$ java Exec 'sh -c $@|sh . echo ps ft' PID TTY STAT TIME COMMAND 27109 pts/25 Ss 0:03 /bin/bash 6904 pts/25 Sl+ 0:00 \_ java Exec sh -c $@|sh . echo ps ft 6914 pts/25 S+ 0:00 \_ sh -c $@|sh . echo ps ft 6916 pts/25 S+ 0:00 \_ sh 6917 pts/25 R+ 0:00 \_ ps ft
