Bug 142281 – bash-completion-20060301 for mount always completes "/dev/shm/" for "/dev"

• Status: RESOLVED UPSTREAM
• Product: Gentoo Linux

[Description Jose daLuz 2006-07-31 07:19:03 UTC]

Most mount commands use a device from /dev as the device parameter. The default fstab setup for Gentoo mounts a tmpfs at /dev/shm. So when you start a mount command with "/dev" or even "/d" as the device parameter and hit tab, "/dev/shm/" is the completion.

Aside from the annoyance involved, isn't this incorrect anyway? "/dev/shm" is a mount point in fstab, not a device, even though the mounted fs ends up being both.

This behavior happens with bash-completion-20060301. I seem to recall it happening before this release, but I could be wrong.

Portage 2.1.1_pre4-r1 (default-linux/amd64/2006.0, gcc-4.1.1/amd64-vanilla, glibc-2.4-r3, 2.6.17-ck1-r2 x86_64)
=================================================================
System uname: 2.6.17-ck1-r2 x86_64 AMD Athlon(tm) 64 Processor 3000+
Gentoo Base System version 1.12.1
ccache version 2.4 [enabled]
app-admin/eselect-compiler: 2.0.0_rc2-r1
dev-lang/python:     2.4.3-r1
dev-python/pycrypto: 2.0.1-r5
dev-util/ccache:     2.4-r2
dev-util/confcache:  0.4.2-r1
sys-apps/sandbox:    1.2.18.1
sys-devel/autoconf:  2.13, 2.60
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2
sys-devel/binutils:  2.16.1-r1, 2.16.93, 2.17, 2.17.50.0.2, 2.17.50.0.3
sys-devel/gcc-config: 2.0.0_rc1
sys-devel/libtool:   1.5.22
virtual/os-headers:  2.6.16
ACCEPT_KEYWORDS="amd64 ~amd64"
AUTOCLEAN="yes"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-march=k8 -O2 -pipe -ggdb"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/lib64/mozilla/defaults/pref /usr/share/X11/xkb /usr/share/config"
CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/eselect/compiler /etc/gconf /etc/java-config/vms/ /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c"
CXXFLAGS="-march=k8 -O2 -pipe -ggdb -ffriend-injection"
DISTDIR="/var/portage/distfiles"
EMERGE_DEFAULT_OPTS=""
FEATURES="autoconfig ccache confcache distlocks fixpackages parallel-fetch sandbox sfperms splitdebug strict"
GENTOO_MIRRORS="http://distro.ibiblio.org/pub/linux/distributions/gentoo/ http://gentoo.osuosl.org/ "
LANG="en_US.UTF-8"
LC_ALL="en_US.UTF-8"
LINGUAS="en"
MAKEOPTS="-j2"
PKGDIR="/var/portage/packages"
PORTAGE_RSYNC_EXTRA_OPTS="--timeout=120"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude='/distfiles' --exclude='/local' --exclude='/packages'"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage /usr/local/bmg-main /usr/portage/local/layman/gentopia /usr/portage/local/layman/sunrise /usr/portage/local/layman/portage-xgl /usr/portage/local/layman/break-my-gentoo-main"
SYNC="rsync://rsync.namerica.gentoo.org/gentoo-portage"
USE="amd64 X aac alsa avi bash-completion berkdb bitmap-fonts bzip2 cairo cdr cli crypt cups dbus debug dlloader dri dvd dvdr eds emboss encode esd firefox flac foomaticdb fortran gdbm gif glitz gnome gpm gstreamer gtk gtk2 hal imlib ipv6 isdnlog java jpeg kde kdehiddenvisibility ldap lzw lzw-tiff mad mono mp3 mpeg ncurses nls nptl nptlonly ogg opengl pam pcre pdflib perl pic png pppd python qt qt3 quicktime readline reflection ruby samba sdl session spell spl sqlite ssl tcpd theora tiff truetype truetype-fonts type1-fonts unicode usb userlocales vorbis xml xml2 xorg xpm xv zlib elibc_glibc input_devices_keyboard input_devices_mouse input_devices_evdev kernel_linux linguas_en userland_GNU video_cards_vesa video_cards_nvidia"
Unset:  CTARGET, INSTALL_MASK, LDFLAGS

[Comment 1 Jose daLuz 2007-03-02 04:02:24 UTC]

This no longer happens, though bash-completion is still at the same version. So perhaps some other package was at fault, but has been fixed in the meantime?

[Comment 2 Tim Boundy 2007-03-02 04:29:13 UTC]

This is still an issue for me, and I did an emerge -DuNav world yesterday (running ~x86).

[Comment 3 Santiago M. Mola (RETIRED) 2008-12-21 11:45:48 UTC]

It seems that any attempt to complete mountpoints is pointless, since any path is potentially valid for mount. I'd say that mount completion needs rework, and mountpoint completion should be removed.

[Comment 4 Jeremy Olexa (darkside) (RETIRED) 2009-04-17 04:41:58 UTC]

I really have looked at this bug multiple times for the past few weeks and could never formulate a response. I simply think it is not possible or desirable to fix. How would tab completion know what to complete? If it looks at fstab, then you know what you are mounting already and you can complete it via mount mntpnt<tab>. So..yea, don't know what to tell ya.

https://alioth.debian.org/tracker/?atid=413095&group_id=100114&func=browse <- upstream bug tracker.