[Bash-completion-devel] Bug#551707: dlocate does not complete filenames

David Paleino dapal at debian.org
Sun Dec 27 21:49:31 UTC 2009


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fix_551707.patch
Type: text/x-patch
Size: 1004 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/bash-completion-devel/attachments/20091227/2a9dd309/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.alioth.debian.org/pipermail/bash-completion-devel/attachments/20091227/2a9dd309/attachment-0001.pgp>


More information about the Bash-completion-devel mailing list