Ville Skyttä wrote:
No, because the time taken by have() within bash-completion is already 0, and we want to don't want to encourage anyone to use it any more by making it faster, we want it to go away. And while it's there, we do want to share code in have() and _have() (and the latter still does have a purpose). But seriously, in case it was not clear already, I am personally not going to make the suggested changes. And I have a hunch that something's probably not right in your bash-completion 2.1 setup -- have() shouldn't be that much of a performance issue unless you have lots of 3rd party completions that use it (which I respectfully doubt) and the function definition you posted isn't like that in 2.1...
---- Actually, due to recent file re-orgs, 'bash-completion' is on my /usr/share/ now, which, as a shared resource, gets mounted separately from root and /usr...with /etc/bash_completion.d being dual-owned by bash and systemd. But the culprit may be bash:
grep completion /etc/bash.*
/etc/bash.bashrc: if test -e /etc/bash_completion ; then /etc/bash.bashrc: . /etc/bash_completion --- But /etc/bash_completion.sh which doesn't seem to be owned by any package but sources /usr/share/bash-completion/bash_completion Ah... so yes... I'd agree, I'm not sure where some of these things are coming from... I'll have to spend some time on this-- of course where I really noticed the performance impact was on cygwin -- which likely has a completely different set of packages owning the same files.... So sorry for the premature bother... as soon as I saw systemd's involvement, I realized something was off... _______________________________________________ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/bash-completion-devel
