How do I escape double quotes and NOT get “quot” when sending a command (Jsch) to an SSH server in Java?

Question

I'm at my wits end here trying to figure out something that should be simple. After trying almost everything I read on Google, I still haven't figured it out. I have an Android app that uses JSCH to connect to an SSH server that processes various commands. The connection is fine and I can run commands, just not anything with double quotes. The command I would like to run on the remote machine is:

start "" "scriptname" "variable"

Note: the "" after start is required.

In my Android app, the command is issued as a String (setCommand only takes a String or byte) with:

ChannelExec exec_channel=(ChannelExec) session.openChannel("exec");
BufferedReader in=new BufferedReader(new InputStreamReader(exec_channel.getInputStream()));
exec_channel.setCommand("start \"\" \"scriptname\" \"variable\"");

After numerous attempts such as simply escaping the double quotes the normal way (ie \\"\\"), storing the double quotes in a char and calling it, and storing it in a byte, I still can't get the receiving SSH server to get the double quotes.

After checking the SSH server logs, it turns out the SSH server is receiving "quot;" in place of the double quotes. How can I escape the double quotes without Android parsing it to "quot;" and receive it properly on the SSH server?

Answer 1

I forgot about this question and just remembered to update, so posting my answer in case someone else runs into the issue. Unfortunately, I was wrong in what the actual problem was. As it turns out, my "setCommand" in Jsch was working correctly with the URL encoding, it was the script being run that had the issue (ie not being able to make any GUI changes). After updating the script to simply echo out a text file, it had turned out the script was actually being run.

As for why I was getting the "quot;" in my logs, I thought it was the issue because it was the only thing popping up as weird in the SSH logs, however I came to realize that it was simply the way the SSH server parsed out the string rather than interpreting it (in other words the SSH server kept it in plain text -- as it should -- when logging).