scp: remote filenames get escaped twice

[14mRh4X0r]

Describe the bug

Since OpenSSH 9.0, scp uses the sftp protocol by default, so it only needs single escaping.

To reproduce

1. Complete a remote filename destination which needs escaping, e.g. my file.pdf
2. Spaces in the remote filename get completed as \\\ , e.g. remote:my\\\ file.pdf
3. When executed, the local file gets copied to a remote file named my\ file.pdf instead of my file.pdf

Expected behavior

Special characters in the remote filename get completed using a single backslash, e.g. remote:my\ file.pdf

Versions (please complete the following information)

• Operating system name/distribution and version: Arch Linux
• bash version, echo "$BASH_VERSION": 5.3.8(1)-release
• bash-completion version, (IFS=.; echo "${BASH_COMPLETION_VERSINFO[*]}"): 2.17.0

Additional context

Passing -O to scp uses the old method, thus still requiring double escaping.

Debug trace

I don't think one is needed for this issue.

[akinomyoga]

#910 was supposed to fix this issue, but I realized we didn't fix it for the scp command at that time because

From #910 (comment)

scp somehow accepts both variants, so this change won't break it.

However, even if the upstream change doesn't affect the remote file as a source filepath, the present issue reports that it still affects destination filepaths.

[yedayak]

I think we might need to version detect ssh :(
Trying to run and old scp version (OpenSSH_7.4p1, in ubuntu 12), if you copy to a destination with single backslashes, it fails with this error:

$ scp anaconda-ks.cfg localhost:/tmp/jajaja\ \ jaja
scp: ambiguous target

The destination file needs 3 backslashes for spaces in OpenSSH<9 (according to relnotes), and a single backslashes in OpenSSH>9

[akinomyoga]

I collected the results of ssh -V on different machines.

OpenSSH_7.2p2 Ubuntu-4ubuntu2.10, OpenSSL 1.0.2g  1 Mar 2016
OpenSSH_8.7p1, OpenSSL 3.5.1 1 Jul 2025
OpenSSH_8.9p1 Ubuntu-3ubuntu0.3, OpenSSL 3.0.2 15 Mar 2022
OpenSSH_9.8p1, OpenSSL 3.2.2 4 Jun 2024
OpenSSH_10.0p2, OpenSSL 3.0.18 30 Sep 2025
OpenSSH_10.2p1, OpenSSL 3.6.0 1 Oct 2025

I think we can consistently obtain the version with [[ $(ssh -V 2>/dev/null) =~ OpenSSH_([0-9]+)\. ]].

[scop]

Having to use ssh to detect scp version is a bit meh, but in reality setups with the latter installed without the former (or a version mismatch with them) are likely very rare.

As an alternative, I suppose we could try and detect if scp accepts -O, e.g.

[[ $(scp --usage 2>&1) =~ scp\ \[-[^]]*O ]]`

...which doesn't give me a warm fuzzy feeling either, but maybe slightly better 🤷