[Bash-completion-devel] hostname completion issues

Freddy Vulto fvulto at gmail.com
Fri Jun 19 22:38:52 UTC 2009


On Thu, Jun 18, 2009 at 10:34 AM, Guillaume
Rousse<Guillaume.Rousse at inria.fr> wrote:
> And I favor the splitted solution because:
> - calling directly the function with the proper behaviour is faster than
> having this function test its argument at runtime to select which behavior
> to use
> - distinguishing between completion functions (those directly attached to a
> command) and helper functions (those called by completion functions) make
> the code easier to maintain

Right now the differences are that _known_hosts:
- clears COMPREPLY (_known_hosts_real does not)
- determines cur=`get_cword` (_known_hosts_real does not)

I think I'm in favour of the splitted solution as well (especially
because of the unnecessary calls to `get_cword'), although I'd prefer
another name instead of `..real'.  Maybe we can call these helper
functions `add...', e.g. `_add_known_hosts', since they *add* to
COMPREPLY where the directly called functions *set* COMPREPLY.
More suggestions?

Should we rename all helper functions, e.g. _filedir > _filedir_real
(or _add_filedir), _services > _services_real (or _add_services),
etc.?  Or is this something to defer till after we branched off bash-2
support?

Another issue regarding function names, maybe also better to do till
after we dropped bash-2 support, is namespaces.  We're using quite
common function names and I can image bash completion functions
clashing with user defined functions, e.g. _cd().  Shouldn't we prefix
all functions with _bc_ or _comp or ? (suggestions?) to simulate some
kind of namespace in which we avoid function name conflicts out there?

> - bash isn't wise enough to to distinguish between an empty string argument
> and an non-existing one: calling the '_known_host -a' function with no
> current host will call '_known_host_real -h "" -a', and result in completion
> for hosts called -a*

I'm not sure if this is really the problem or if this happened because
getopts encountered an empty string in the middle of the options (see
previous reply)?  Turning the -h option into a mandatory argument is
fine with me too, I think I don't really understand your point, but
feel free to change.
I see e.g. _filedir and _services are also relying on a global `cur'
:-(  I think it would be better for all helper functions not to rely
on globals and pass `cur' to them as an option/argument?  But maybe
this is not the right time/branch to change it all.  Maybe we should
try to get more consensus about what everybody think is desired.
We can also restore the `ocur' backup variable to `_known_hosts_real'
so at least all helper functions are working the same, i.e. relying on
global `cur'.

Greetings, Freddy



More information about the Bash-completion-devel mailing list