sudo tab autocomplete shows erratic behavior with spaces in names

Bug #470037 reported by Michael DePaulo
34
This bug affects 6 people
Affects Status Importance Assigned to Milestone
bash-completion (Ubuntu)
Fix Released
Undecided
Unassigned

Bug Description

Binary package hint: bash-completion

I have observed this behavior on two machines running Ubuntu AMD64 9.10

To reproduce, open up a terminal with bash
Then go to a directory that contains a folder or directory with spaces in its name.
Type "sudo ./" and then the first part of the name before the space. Ie, if you have "Ubuntu One" in your directory, type:
sudo ./Ubuntu

This will yield output like:
mike@telescreen:~$ sudo ./Ubuntu
One Ubuntu

Going further, if you type:
sudo ./Ubuntu\
(note the space on the end of that)
Hitting tab will yield
mike@telescreen:~$ sudo ./Ubuntu\\\
(with a space on the end)

If you continue and type:
sudo ./Ubuntu\ One/
Hitting tab will yield:
mike@telescreen:~$ sudo ./Ubuntu\\\ One/
hitting tab again with resort to what you originally typed without the extra backslashes/escapes.

ProblemType: Bug
Architecture: amd64
Date: Sun Nov 1 23:30:31 2009
DistroRelease: Ubuntu 9.10
InstallationMedia: Ubuntu 9.10 "Karmic Koala" - Release amd64 (20091027)
NonfreeKernelModules: nvidia
Package: bash-completion 1:1.0-3ubuntu2
PackageArchitecture: all
ProcEnviron:
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-14.48-generic
SourcePackage: bash-completion
Uname: Linux 2.6.31-14-generic x86_64

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

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

Changed in bash-completion (Ubuntu):
status: New → Confirmed
Revision history for this message
Martin Eve (martineve) wrote :

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

Revision history for this message
Eliah Kagan (degeneracypressure) wrote :

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.

tags: added: karmic maverick
Revision history for this message
Eliah Kagan (degeneracypressure) wrote :

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.

Revision history for this message
Michael DePaulo (mikedep333) wrote :

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

Revision history for this message
Eliah Kagan (degeneracypressure) wrote :

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

tags: added: i386 oneiric
Revision history for this message
Romanos Dodopoulos (rwmanos) wrote :

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

Revision history for this message
Aditya V (kroq-gar78) wrote :

Still in Ubuntu 12.04 release as of August 3, 2012

Revision history for this message
Peter Cordes (peter-cordes) wrote :

not present in Trusty. Thanks Romanos for the testcase:

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

Changed in bash-completion (Ubuntu):
status: Confirmed → Fix Released
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.