On Tue, Mar 06, 2007 at 10:47:40AM -0500, cga2000 wrote: > > I was also surprised that bash can do this. I played around with it a > > bit and found that my bash can do the "*xx*<tab>" completion only if I > > do not source /etc/bash_completion. I have to choose between having the > > "*xx*<tab>" completion behavior and having the handy features offered by > > /etc/bash_completion. I use bash 3.1dfsg-8 on a Sid system. > > > > Can anybody confirm this? Is this a bug or a consequence of the way > > /etc/bash_completion works? (I would expect that bash_completion is > > supposed to add features without removing existing ones.) > I wrote in an other email : > > I may have missed something ; I am running Sid. > > Enabling bash completion, it does not work. However, without bash > > completion it does work ! Where is the trick ? Well, so I am not crazy. That is good :p! I had the same behaviour on Sid (bash : 3.1dfsg-8) and Etch (bash 3.1dfsg-8). > Maybe the "problem" is caused by the use of <TAB> for two different > mechanisms: > > 1. "completion" .. you type the first 0-n characters of an entity, hit > <TAB> and bash will complete what you typed if only one match is > found and beep otherwise. In the latter case you can issue a second > <TAB> and bash will display the list of matches. This feature is > programmable - ie. you can define completion rules to filter > out entities that do not make sense in a given context. > > 2. "pathname expansion": you use special characters and .. optionally > literals to build a pattern, hit <TAB> and bash expands your pattern > into a list of matching entities. > > Since pathname expansion returns a list of fully-named entities it seems > that a different filtering mechanism than programmable completion would > be needed: something that lets you filter out fully-named entities that > do not make sense in a given context -- rather than what programmable > completion offers: conditionally completing your input according to the > rules specified in /etc/bash_completion. > > Kinda hard to explain but it doesn't strike me as a bug -- functional > or otherwise. -- Franck Joncourt http://www.debian.org http://smhteam.info/wiki/ GPG server : pgpkeys.mit.edu Fingerprint : C10E D1D0 EF70 0A2A CACF 9A3C C490 534E 75C0 89FE
Attachment:
signature.asc
Description: Digital signature