bash-completion
bash-completion copied to clipboard
scop
fix(rsync,ssh): do not overescape spaces in remote filenames
Fixes #848.
If a remote machine contains a file named a b, completing rsync command results in rsync remote:a\\\ b, which results in rsync failing to find the file.
This commit removes the extra slashes, and now completion results in rsync remote:a\ b.
scp somehow accepts both variants, so this change won't break it.
Can we detect the rsync version and switch the behavior depending on whether the version is lower than 3.2.4 or not? 3.2.4 (2022-04) seems still new, so we expect there are still two different types of rsync in the market.
Sure, but that'll require an extra call to rsync --version and an ugly extra argument to _comp_xfunc_ssh_scp_remote_files.
I've added a commit with the rsync version check.
However, if I were a maintainer, I'd much prefer the simpler solution of just working with the latest version. By the time bash-completion 2.12 is released and propagates to the distributions, it is likely that rsync will also be updated in those distributions. It would be strange if bash-completion were updated while rsync remained on an older version.
I've done a quick check on the distributions:
- Ubuntu 22.04 LTS has rsync 3.2.7 (after security update)
- Ubuntu 22.10 has rsync 3.2.7
- Debian stable has rsync 3.2.3
- Debian testing has rsync 3.2.7
- Fedora 36-38 has rsync 3.2.7
Arch Linux, of course, has the latest version. I was actually quite surprised to find out that Arch still uses bash-completion from 2020.
From a maintenance perspective, I believe it would be much better not to check the rsync version, as this significantly complicates the code.
I have a question. The function _comp_xfunc_ssh_scp_remote_files seems to be also called from the completions for other commands ssh and sshfs. I guess we want to keep the original behavior for these commands. Or did these commands also change its interpretation of the escapes?
It was my understanding that they accept both versions of these arguments (tested on my versions), but I'm not sure for how long they had this behavior. I'll invert the check so that we only change the behavior for the newer rsyncs.
However, if I were a maintainer, I'd much prefer the simpler solution of just working with the latest version. By the time bash-completion 2.12 is released and propagates to the distributions, it is likely that rsync will also be updated in those distributions. It would be strange if bash-completion were updated while rsync remained on an older version.
Users are allowed to anytime download the latest version of bash-completion from GitHub independently of the OS distributions.
From a maintenance perspective, I believe it would be much better not to check the rsync version, as this significantly complicates the code.
Ubuntu LTS 18.04 will soon expire, but LTS 20.04 (with rsync 3.1.3) will still continue to be maintained until 2025-04. That's the idea of LTS. Also, we perform CI tests under Debian 10 (w/ rsync 3.1.3), CentOS 7 (w/ rsync 3.1.2), and Ubuntu 14.04 (w/ rsync ???). We actually support as old Bash as 4.2, (which is the reason that we have tests in Ubuntu 14.04).
It was my understanding that they accept both versions of these arguments (tested on my versions), but I'm not sure for how long they had this behavior. I'll invert the check so that we only change the behavior for the newer rsyncs.
Thank you. I think that's safer for now.
Applied changes according to comments.
Regarding scp_remote_files test - added tests that expect LIVE_HOST remote files to include file spaces in filename.txt.
I got bitten by this problem today. Would it be possible to get this merged, please? This is also referred in https://www.reddit.com/r/pop_os/comments/124jmp1/synchronizing_rsync_so_it_only_singlequotes/ Thanks a lot!
