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 > Bash-completion-devel@lists.alioth.debian.org > http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel _______________________________________________ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel