Seriously I don't know, but maybe to avoid the problem hitted
when you do, as unprivilieged user (U.P.):
/sbin/iptables -j <TAB>
I think it's a deep problem I don't remember having heard about :
the completion of commands which :
1) are in {,/usr}/sbin
2) but are usable "read-only" by an U.P.
It's sometimes usefull for a U.P. to use modprobe <TAB>
(Notice the $PATH and ifconfig in ubuntu for example)That's why I think the current have() is not enough if the current behavior is considered as a problem. What about this kind of have() : - return 0 if found - return 1 if not found - return 2 if we needs another $PATH than the user's original one In this later case, we may use something like $(have -p $cmd) to get the absolute path echoed and use it if needed. Or a backward compatible solution : - echo the absolute path of the command if found - return 1 otherwise my 2c Raph On Thu, Jun 18, 2009 at 05:43:41PM +0200, Mark Rosenstand wrote: > Hi, > > Sorry for not reporting this through the bug tracker, I'm a bit short on time > but thought this is trivial enough to fix through a simple mail. > > The path to lsmod seems to be hardcoded in 1.0 and git, making > modprobe -r completion bomb out on my system with a vanilla > module-init-tools 3.9 (./configure --prefix=/usr --exec-prefix=) > > _______________________________________________ > Bash-completion-devel mailing list > [email protected] > http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel _______________________________________________ Bash-completion-devel mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
