tags 551707 - unreproducible tags 551707 confirmed patch reassign 551707 dlocate thanks
On Sunday 27 December 2009 22:07:45, Norbert Preining wrote: > On Sun, 27 Dec 2009, David Paleino wrote: > > tags 551707 unreproducible > > Strange. I had bash-completion purged from my system. > > Now I installed it. > > Then I did > dlocate /usr/s<TAB><TAB> > and again nothing nothing nothing. ..and, turns out that we're not handling it, at all. It's in the dlocate package, bug reassigned. > Can you guarantee that you are not using something else then what there > is in the sid repository??? Just re-checked it on a sid chroot, and I'm now confirming it. Sorry for not doing this at first :) > Please tell me what info I can provide to debug that, [..] Nothing, I'm attaching a patch which fixes the problem. On first try I just forgot to re-login, thus I wasn't really using bash-completion on it. Sorry for the noise :) dlocate maintainers: you could also consider letting us (bash-completion) handle the completion upstream; this way we would keep it up-to-date with our API (see note about _get_pword in >1.1). If you want it to be included upstream, please file a bug against us, I will handle that. Thanks :) > but I have to purge bash-completion until you ask me, because currently it > is as useful as a keyboard filled with coke. Please, please, don't continue on this line. I'm more than willing to fix bugs and implement new things, like all other people in the team do, but please don't act like this, nobody is forcing you to use it ;) And, as always, if you don't like something, patches are welcome! > > > Again, that would be solved by what I have reported in another bug, > > > namely that bash-completion defaults to path completion if nothing else > > > can be found .... > > > > I believe this would involve changing each completion, providing "compgen > > -f" in COMPREPLY if nothing is found. > > Well, still that is something that might be interesting, maybe implemented > in a different way. > > The point here is that if nothing is found, maybe the completion > algorithm is incomplete ... or forgot some options ... you never know > in what ways people abuse the system. And then it should fall back > to what normal bash would do by default, namely complete the path. AFAICT, with the current structure of bash-completion, you can't do any "global" thing. So you can't "complete on filenames" when "nothing is found" -- you have to handle it per each completion. Please file a separate bug if you want to continue on this point, as we're also planning a rewrite of bash-completion in future, so we might consider some "global wrapper", which would fit this particular need. Ciao Norbert, e Buone Feste! :) David -- . ''`. Debian developer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 ----|---- http://snipr.com/qa_page `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174
From: David Paleino <da...@debian.org> Subject: handle filedir completion for dlocate, plus some overall improvements Bug-Debian: http://bugs.debian.org/551707 --- /tmp/dlocate-completion.old 2009-12-27 22:37:49.000000000 +0100 +++ dlocate-completion 2009-12-27 22:42:13.000000000 +0100 @@ -6,27 +6,29 @@ local cur prev COMPREPLY=() - cur=${COMP_WORDS[COMP_CWORD]} + cur=$(_get_cword) + # the following can be substituted with $(_get_pword) on bash-completion >1.1, not yet released prev=${COMP_WORDS[COMP_CWORD-1]} case "$prev" in -S) _filedir - return 0 ;; -@(L|l|s|ls|du|conf|lsconf|md5sum|md5check|man)) COMPREPLY=( $( _comp_dpkg_installed_packages $cur ) ) - return 0 ;; - *) + esac + + case "$cur" in + -*) COMPREPLY=( $( compgen -W '-h -H -V -S -L -l -s -ls -du \ -conf -lsconf -md5sum -md5check -man --help \ --version' -- $cur ) ) - return 0 + ;; + *) + _filedir ;; esac - - # notreached return 0 } complete -F _dlocate $filenames dlocate
signature.asc
Description: This is a digitally signed message part.
