And no, it's not bug #98627. Since 20050712, bash-completion causes aliases on several coreutils and other oft used toold not to be treated as such, if completion was invoked on the line. Like so: [~] alias ls='echo Larry the Cow hates ' [~] ls /bi<TAB> [~] ls /bin/ <lists /bin> [~] ls /bin/ Larry the Cow hates /bin/ This breaks setting the options through an alias on at least ls, rm and grep, but not on everything. I'm totally clueless on bash's completion so can't provide a fix. Reproducible: Always Steps to Reproduce: Portage 2.0.51.22-r1 (default-linux/amd64/2005.0, gcc-3.4.4, glibc-2.3.5-r0, 2.6.12-gentoo-r4 x86_64) ================================================================= System uname: 2.6.12-gentoo-r4 x86_64 AMD Athlon(tm) 64 Processor 3000+ Gentoo Base System version 1.6.13 ccache version 2.4 [enabled] dev-lang/python: 2.3.5, 2.4.1-r1 sys-apps/sandbox: 1.2.11 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6 sys-devel/binutils: 2.16.1 sys-devel/libtool: 1.5.18-r1 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="amd64 ~amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -march=k8 -fomit-frame-pointer -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -march=k8 -fomit-frame-pointer -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig candy ccache collision-protect distlocks sandbox sfperms strict userpriv usersandbox" GENTOO_MIRRORS="http://ftp.belnet.be/mirror/rsync.gentoo.org/gentoo/ http://gentoo.oregonstate.edu http://www.ibiblio.org/pub/Linux/distributions/gentoo" LANG="en_US.UTF-8" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage-overlays/misc" SYNC="rsync://deimos.ffzg.hr/gentoo-portage" USE="amd64 X a52 aac aalib acpi alsa aotuv avi bash-completion berkdb bzlib cdparanoia cdr crypt curl directfb doc dpms dvd dvdr dvdread edl encode faad fbcon fbdev foomaticdb fortran framebuffer freetype gd geoip gif gstreamer gtk2 imagemagick imlib ithreads jack jack-tmpfs jpeg kdeenablefinal live lzo lzw lzw-tiff mad maildir matroska mng mp3 mpeg musepack ncurses network nls nodrm nptl nvidia offensive ogg oggvorbis opengl openssl pam pcre pdflib perl pic png python qt quicktime readline real rtc ruby sdl sndfile soundtouch spell sqlite ssl stroke svg sysfs tcpd tga threads tiff truetype-fonts unicode usb userlocales v4l v4l2 vorbis xine xml xml2 xpm xprint xv xvid xvmc yv12 zlib video_cards_nvidia userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LC_ALL, LDFLAGS, LINGUAS
(In reply to comment #0) > Like so: > > [~] alias ls='echo Larry the Cow hates ' > [~] ls /bi<TAB> > [~] ls /bin/ > <lists /bin> > [~] ls /bin/ > Larry the Cow hates /bin/ Sorry, you report is not quite clear, so a quick question: you aliased ls to the above shown example *yourself*?
Obviously, which is about the same as aliasing it at any other point in the shell's lifetime after sourcing /etc/profile.d/bash_completion. ~/.bashrc comes to mind. Just try the exact same sequence -- if it feels a bit on the difficult side to generalise, try, say, aliasing "rm" to "rm -i", touch-ing an arbitrary file, typing in "rm" followed by the first few chars of the file's name, tab-completing the rest and pressing enter. What i get is anything but a confirmation prompt. Tab completing filenames after grep causes the aliased "--color" not to kick in. Typing it in entirely works normally. Same for ls. Not the same for arbitrary aliases without a corresponding name in the bin namespace, not the same for some other commands whose names are also aliased to expanded sequences with arguments. Therefore i'd assume the new bash-completion is stripping aliases to protect internal completion functions from breaking under unexpected behavior but i just can't read through the actual script and understand it.....
Using tab-complete discards aliases: nelchael@nelchael ~$ alias ls alias ls='ls -shFX --color=no' nelchael@nelchael ~$ ls e/ total 792K 132K 1 132K 2 132K 3 132K 4 132K 5 132K 6 nelchael@nelchael ~$ ls e/ <--- used TAB to get the slash 1 2 3 4 5 6 nelchael@nelchael ~$
(In reply to comment #3) > Using tab-complete discards aliases: Now it's much more clear, thanks. :)
a ha! I've been experiencing this too and could not figure out what the hell was causing it. I couldn't figure out why if I typed the command the first type the alias wasn't picked up but if I did it subsequently it worked (because I was using the up arrow and hitting enter ;p). Not sure if I'll have enough time to look into this today, but if not definitely tomorrow.
It looks like there is a new version of bash-completion, 20050720. Looking at the Changelog doesn't seem like this problem is fixed, but who knows. http://www.caliban.org/bash/index.shtml#completion Damn, I wasted so much time trying to figure out why my aliases weren't working... glad it's not just me.
(In reply to comment #6) > It looks like there is a new version of bash-completion, 20050720. Looking at > the Changelog doesn't seem like this problem is fixed, but who knows. Yeah I got the release announcement last night. Just got home from work, so it'll be in portage within a few hours. Hopefully he fixed this and just didn't mention it in the changes list.
eh nope not fixed. I might hold off bumping it until I figure out what's causing this.
I sent an email to the author pointing him to this bug, in case he doesn't know about it yet.
Apparently this is a bug in bash. Here is Ian's email to the bash bug mailing list, which he CC'd me on: Hi, This is a bit of a corner case, but appears to be a bug. If one defines a completion function that calls 'set +o noglob' and this function is then bound to a command, alias expansion is temporarily disabled when the command is executed. If the command is subsequently executed again without calling the completion function, alias expansion occurs as normal. For example: [ianmacd@sagan i386]$ set +o | grep noglob set +o noglob [ianmacd@sagan i386]$ _foo() { local glob=$(set +o|grep noglob); set -f; eval "$glob"; } [ianmacd@sagan i386]$ complete -F _foo -o filenames ls [ianmacd@sagan i386]$ alias ls="echo ALIAS! $1" [ianmacd@sagan i386]$ ls ~/foo<Enter> ALIAS! /home/ianmacd/foo [ianmacd@sagan i386]$ ls ~/foo<Tab><Enter> accesses.db day12-5 day17-2 divzero prog4 anagram day13-1 day17-3 editor.rb prog5 buzz.db day13-2 day17-5 executables runcom.rb callanalyzer day13-3 day17-6 fib_test_2.rb spinner1.rb cards day13-4 day18-1 findbox.rb spinner2.rb cards.rb day14-2 day18-4 foo spinner3.rb cards2 day14-3.1 day18-5 index.html spinner4.rb cards3 day14-3.2 day18-6 inner.rb spintest.rb cards4 day14-3.3 day19-1 messagebox.rb student.rb complex.rb day14-4 day19-2.rb outer.rb teacher.rb datagram.rb day15-2 day20-1 p302 ty_ruby_21_listings day10-1 day15-4 day20-2 prog1 ty_ruby_21_listings.tgz day11-2 day15-5 day20-3 prog2 day12-4 day15-6 deck.rb prog3 [ianmacd@sagan i386]$ bash --version GNU bash, version 3.00.16(1)-release (i686-redhat-linux-gnu) Copyright (C) 2004 Free Software Foundation, Inc. As you can see, in this second invocation, the alias was not used as it should have been. Ian
base-system guys, comments?
what do you expect us to say ? if it's a bug in bash, post a patch ;P
bash-completion version 20050721 fixes this. http://www.caliban.org/bash/index.shtml#completion No word on the bash bug though.
Well it wasn't "fixed", just the offending code that triggers the bash-3 bug was removed. Latest bash-completion is in cvs.
*** Bug 99924 has been marked as a duplicate of this bug. ***
The bash bug mentioned here has been fixed for bash 3.1, according to a posting on the bash bugs mailing list.
