2006-03-01 15:19:26 +00:00
|
|
|
bash completion needs to be rewritten from the ground up.
|
|
|
|
|
---------------------------------------------------------
|
|
|
|
|
|
|
|
|
|
bash completion really needs to be rewritten from the ground up, using all of
|
2011-04-21 12:20:59 +03:00
|
|
|
the features available in bash 4.1+ and without regard for compatibility with
|
2010-01-24 21:06:42 +02:00
|
|
|
earlier versions.
|
2006-03-01 15:19:26 +00:00
|
|
|
|
|
|
|
|
At that time, it should be split into multiple files for easier source
|
|
|
|
|
management. Whether or not it is actually installed on the destination
|
|
|
|
|
computer as separate files is a matter for future debate.
|
|
|
|
|
|
|
|
|
|
If it were installed as tens or even hundreds of files, each of which had to
|
|
|
|
|
be opened to decide whether it should be sourced in its entirety, that could
|
|
|
|
|
prove very expensive on some systems.
|
|
|
|
|
|
|
|
|
|
Alternatively, a master file could decide which of the individual completion
|
|
|
|
|
files should be sourced. In that way, we wouldn't need to open extra files
|
|
|
|
|
just to ascertain that the commands for those functions aren't on the system,
|
|
|
|
|
anyway.
|
|
|
|
|
|
|
|
|
|
A further alternative is that a build process be created, which would
|
|
|
|
|
concatenate the various files into a single completion file, similar to what
|
|
|
|
|
we have now. This option is my least favourite, because a system with a lot of
|
|
|
|
|
packages installed currently has to deal with sourcing over 200 kB of bash
|
|
|
|
|
code for each invocation of an interactive shell.
|
|
|
|
|
|
|
|
|
|
An even better alternative would be if bash supported dynamic loading of shell
|
|
|
|
|
functions (in the manner of zsh), but I don't believe there are any plans to
|
|
|
|
|
add this feature.
|
|
|
|
|
|
|
|
|
|
--
|
|
|
|
|
Ian Macdonald
|
|
|
|
|
Amsterdam, March 2006
|
