bash completion for scp overescapes spaces and does not correctly re-filter ("\\\ " instead of "\ ")

Bug #482753 reported by Martin Eve
20
This bug affects 3 people
Affects Status Importance Assigned to Milestone
bash-completion (Ubuntu)
Fix Released
Undecided
Unassigned
Lucid
Won't Fix
Undecided
Unassigned

Bug Description

Binary package hint: bash-completion

OS: Karmic 9.10

Directory structure on target:

/home/martin/directory 1/directory 2/file.txt

Type:

scp target:/home/martin/directory<TAB><TAB>

Expected:

scp target:/home/martin/directory 1/directory 2/

Actual:

scp target:/home/martin/directory\\\ 1/

To summarise, it is impossible to do any further autocompletion once the \\\ escape sequence has been given.

This is caused by the incorrect line:

  # unescape spaces
  path=${path//\\\\\\\\ / }

in contrib/ssh

It should, instead, read:

  # unescape spaces
  path=${path//\\\\}

Aiming to do a fix for this asap.

Revision history for this message
Martin Eve (martineve) wrote :
Changed in bash-completion (Ubuntu):
status: New → Confirmed
tags: added: regression-release
Revision history for this message
Colin Watson (cjwatson) wrote :

You say "overescapes", but scp is buggy at a protocol level and actually does require this double-escaping. Demonstration:

  <cjwatson@riva ~>$ touch 'file with spaces'
  <cjwatson@sarantium ~>$ scp riva:file\ with\ spaces .
  scp: file: No such file or directory
  scp: with: No such file or directory
  scp: spaces: No such file or directory
  <cjwatson@sarantium ~>$ scp riva:file\\\ with\\\ spaces .
  file with spaces 100% 0 0.0KB/s 00:00

Are you quite sure that your patch is correct, in light of this?

Revision history for this message
Martin Eve (martineve) wrote :

Hi,

This patch doesn't actually change the input passed to scp, but rather alters the way that scp completes on the bash prompt.

For example, say on the remote server I have:

~/Hello Folder One
~/Hello Folder Two
~/Hello Different Three

Typing:

scp -r remote:~/Hell[TAB]

will result, with this patch with:

scp -r remote:~/Hello\\\

Now, in the old system if you then went:

scp -r remote:~/Hello\\\ F[TAB]

Nothing would happen. The \\\ was incorrectly handled when asking for a directory listing to then parse with sed.

With the patch, the prompt now reads:

scp -r remote:~/Hello\\\ Folder\\\

as would be expected, and you can continue.

Once the line is complete (scp -r remote:~/Hello\\\ Folder\\\ O[TAB] -> scp -r remote:~/Hello\\\ Folder\\\ One) you can press enter and the scp action will continue correctly (because the line still uses \\\)

tl;dr: the patch keeps \\\ on the command line, but just parses them correctly when it tries to get a remote directory listing

Revision history for this message
Martin Eve (martineve) wrote :

As one additional point to above, this patch also handles:

scp -r remote:~/Hello\ Fol[TAB]

which will result in:

scp -r remote:~/Hello\\\ Folder\\\

so basically, it standardizes \[SPACE] to \\\[SPACE] but also allows for repeated completions using either scheme.

Martin Eve (martineve)
tags: added: lucid
Revision history for this message
Martin Eve (martineve) wrote :

This issue is still present in Lucid.

This single line patch works and has been tested (as the many comments at https://bugs.launchpad.net/ubuntu/+source/bash-completion/+bug/449349 will testify.

Please review as a fix for this regression in Lucid.

Martin

Revision history for this message
Martin Eve (martineve) wrote :

Note: this bug is fixed upstream in *version control*.

However, upstream will certainly not release in time for Lucid, hence the patch here.

Revision history for this message
Thierry Carrez (ttx) wrote :

Upstream has a more complete fix, hinting that the first patch would still fail for paths containing other backslash escaped chars besides spaces.

We should consider having that instead ?

Revision history for this message
Martin Eve (martineve) wrote :

@Thierry: Yes, I see what you mean; scp completion on directories with other special characters does, indeed, fail with this patch.

It would be nice to have their more complete fix, but (unless we sync the entire unstable git branch) I don't know how the contrib/ssh component will interact with the stable bash-completion script.

I would certainly be in favour of such a sync; the current state of scp completion is unusable.

What do you think?

Revision history for this message
Sebastien Bacher (seb128) wrote :

unsubscribing the sponsors for now since the previous comment indicate the fix there has issues and another one should be backported from upstream, ideally a bug would be opened on the debian bts about that as well about the issue

tags: added: patch
Revision history for this message
Bryce Harrington (bryce) wrote :

[The patch is no longer relevant to oneiric; opening a Lucid task instead.]

Changed in bash-completion (Ubuntu Lucid):
status: New → Confirmed
Changed in bash-completion (Ubuntu):
status: Confirmed → Fix Released
Revision history for this message
Rolf Leggewie (r0lf) wrote :

lucid has seen the end of its life and is no longer receiving any updates. Marking the lucid task for this ticket as "Won't Fix".

Changed in bash-completion (Ubuntu Lucid):
status: Confirmed → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.