sudo tab autocomplete shows erratic behavior with spaces in names

I am able to reproduce this bug which is also present in Jaunty.

Furthermore, this is not AMD64 specific; I am replicating on i386.

I can reproduce this bug on Maverick amd64 with bash 4.1-2ubuntu4 and bash-completion 1:1.2-2ubuntu1.

In addition (I believe this can be considered part of the same bug), bash-completion works fine with umount without sudo, but when I start a command "sudo umount /media/New" with the intention that it will tab-complete to "/media/New Volume", instead it tab-completes to "sudo umount /media/New\\\ Volume". If I press tab again, it appends an additional "/", and if I press tab twice more after that, it prints out a garbled list constructed from the list of mounted volumes:

// New\ Volume
boot/ Wingardium/
dev/ proc/
ee08e8b3-dffd-45c0-bd04-b74dd72a705b mountPoint/
pts/ binfmt_misc/
sda3 sys/
sda5 connections/
sdb1 debug/
sdc1 security/
shm/ lock/
.gvfs/ run/
Alucard/

For comparison, here's the output of "mount":

/dev/sda7 on / type ext4 (rw,errors=remount-ro,commit=0)
proc on /proc type proc (rw,noexec,nosuid,nodev)
none on /sys type sysfs (rw,noexec,nosuid,nodev)
fusectl on /sys/fs/fuse/connections type fusectl (rw)
none on /sys/kernel/debug type debugfs (rw)
none on /sys/kernel/security type securityfs (rw)
none on /dev type devtmpfs (rw,mode=0755)
none on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620)
none on /dev/shm type tmpfs (rw,nosuid,nodev)
none on /var/run type tmpfs (rw,nosuid,mode=0755)
none on /var/lock type tmpfs (rw,noexec,nosuid,nodev)
/dev/sda5 on /boot type ext2 (rw)
none on /proc/fs/vmblock/mountPoint type vmblock (rw)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,noexec,nosuid,nodev)
gvfs-fuse-daemon on /home/ek/.gvfs type fuse.gvfs-fuse-daemon (rw,nosuid,nodev,user=ek)
/dev/sda3 on /media/Wingardium type fuseblk (rw,nosuid,nodev,allow_other,blksize=4096)
/dev/sdb1 on /media/Alucard type fuseblk (rw,nosuid,nodev,allow_other,blksize=4096)
/dev/sdc1 on /media/New Volume type vfat (rw)

I don't know where the line with the globally-unique identifier and "mountPoint" came from. The answer is probably obvious...I didn't try hard to find it, though I'd be pleased to follow instructions to investigate that or any other aspect of this bug, if it will help in fixing it. Running "sudo updatedb" followed by "locate ee08e8b3-dffd-45c0-bd04-b74dd72a705b" and "locate mountPoint" turned up nothing.

Note that I mounted the volume successfully with the command "sudo mount /dev/sdc1 /media/New\ Volume", and that was correctly produced by tab-completion starting with "sudo mount /dev/sdc1 /media/New". So bash-completion seems to work OK with "sudo mount" (at least in this instance), but not so well with "sudo umount". Erratic indeed.

Ah. I understand the source of all those lines. They're from my /etc/fstab file, which contains:

(File starts on the next line.)
# /etc/fstab: static file system information.
#
# Use 'blkid -o value -s UUID' to print the universally unique identifier
# for a device; this may be used with UUID= as a more robust way to name
# devices that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
proc /proc proc nodev,noexec,nosuid 0 0
# / was on /dev/sda7 during installation
UUID=ee08e8b3-dffd-45c0-bd04-b74dd72a705b / ext4 errors=remount-ro 0 1
# /boot was on /dev/sda5 during installation
UUID=445891f8-3505-4c88-815c-fb4340f7791a /boot ext2 defaults 0 2
# swap was on /dev/sda6 during installation
UUID=a95988d3-98aa-4a18-b21a-93f606808fb2 none swap sw 0 0

# mount Windows 7 partition
#/dev/sda3 /media/Wingardium ntfs rw,nosuid,nodev,allow_other,default_permissions 0 2
(File ends on the previous line.)

Besides the first suggestion given "// New\ Volume", I don't think the others have anything to do with this bug. Tab-completion on "umount " first produces "umount /" and then produces the following list (which I believe is good, correct, and intended behavior):

/
/boot
/dev
/dev/disk/by-uuid/ee08e8b3-dffd-45c0-bd04-b74dd72a705b
/dev/pts
/dev/sda3
/dev/sda5
/dev/sdb1
/dev/shm
/home/ek/.gvfs
/media/Alucard
/media/Wingardium
/proc
/proc/fs/vmblock/mountPoint
/proc/sys/fs/binfmt_misc
/sys
/sys/fs/fuse/connections
/sys/kernel/debug
/sys/kernel/security
/var/lock
/var/run

The original issue, and its apparent selectivity with respect to which command is used with sudo, remains.

I am still experiencing this bug on Oneiric AMD64 with the latest updates.

I can confirm that (with bash 4.2-0ubuntu4 on Oneiric i386).

Reproducible at ubuntu 12.04
It is annoying, I was trying to run (sudo) a program and I couldn't figure where was the directory.

simple example1:
t@ubuntu:~/test$ ls
test test space
t@ubuntu:~/test$ ./test #pressing tab
test/ test space/
t@ubuntu:~/test$ sudo ./test #pressing tab
space test/

OR, example2:
t@ubuntu:~/test$ ls | grep cud
cuda
cuda pdfs
t@ubuntu:~/test$ ./cuda #pressing tab
cuda/ cuda pdfs/
t@ubuntu:~/test$ sudo ./cuda #pressing tab
cuda/ pdfs

Still in Ubuntu 12.04 release as of August 3, 2012

not present in Trusty. Thanks Romanos for the testcase:

mkdir test{,\ space}
./test<tab> => test/ test space/
sudo ./test<tab> => test/ test space/