| Summary: | bash-completion gone evil with 20050712 -- weird behavior of aliases | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | noddy <dkaloper> |
| Component: | Current packages | Assignee: | Gentoo Shell Tools project <shell-tools> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | base-system, kenyon, marduk, nelchael |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
noddy
2005-07-19 08:35:23 UTC
(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. |
