SCPEngine should not quote remote paths

[fbacher]

SCPEngine.execSCPWith wraps the given path with single quotes and adds an escape character to any quotes in the path. This creates problems for some remote systems, such as vxWorks, which, at least on the version I'm communicating with, does not strip the quotes, resulting in invalid file name errors.

• scp should leave it up to the application to properly quote paths
• Applications can not work around the automatic quoting that occurs today
• openssh scp source, does not appear to perform any quoting or globbing of paths.It passes them along as is to the remote shell to handle.

[hierynomus]

Would it work if we escaped the spaces using a \? I agree that the quoting that was previously put in is indeed dangerous and broken. Also see #152 for a PR which fixes it in an even worse way.

[bkarge]

The escaping does not seem to work on Linux, either.
replaceAll("'", "'"'"'") did work for me (http://stackoverflow.com/questions/1250079/how-to-escape-single-quotes-within-single-quoted-strings)

[fbacher]

I think that sshj should do what openssh does.

On Fri, Mar 27, 2015 at 11:33 AM, Björn Karge notifications@github.com
wrote:

The escaping does not seem to work on Linux, either.
replaceAll("'", "'"'"'") did work for me (
http://stackoverflow.com/questions/1250079/how-to-escape-single-quotes-within-single-quoted-strings
)

—
Reply to this email directly or view it on GitHub
#184 (comment).

[bkarge]

I'm not sure, what scp "does". All I see is it "does not care" and subjects the interpretation of the file name to the escaping rules of the target shell (and probably other things).
However, sshj provides a Java API and the semantics clearly are "get me that file", and not run bash -c scp -qf . So I would rather propose an escaping that works in 99.9% of the cases, and to add a possibility to explicitly opt out of escaping if this goes wrong.

[hierynomus]

@fbacher I disagree. I think that SSHJ should be compatible with as many different SSH implementations as possible. This means that the scope is broader than OpenSSH. See for instance the issues against PSFTP, WinSSHD, etc... I indeed want to aim for a near 100% solution like @bkarge says. For this we need to find a correct quoting/escaping. That is not trivial, but the "just send it unquoted" option will definitely not work in a lot of cases.

[jpstotz]

If the correct escaping and/or quoting is that difficult you should make to configurable.
The way it is in v0.13.0 is bad IMHO as it prevents performing SCP commands on remote files that contains a single quote in the filename - example:

/home/user/test'ed

Such a filename can not be used (e.g. download) with sshj at the moment, as the resulting command is:

scp -f -q -p -r '/home/user/test'ed'

[jpstotz]

Furthermore the implemented escaping for single quotes is defect:

SCPEngine line 112:
cmd.append("'").append(path.replaceAll("'", "\\'")).append("'");

The used method replaceAll requires an regex (and a single quote is not a valid regex).
Therefore path.replaceAll("'", "\\'") does not change or escape anything.
Change it to path.replace("'", "\\'")