[Bash-completion-devel] using external helpers for completion
Freddy Vulto
fvulto at gmail.com
Sun Aug 29 22:05:07 UTC 2010
On 100828 18:32, Guillaume Rousse wrote:
> However, I'd like us to decide on a final setup, that would be:
> 1) FHS-compliant
> 2) efficient in term of time spent to source files at each new bash
> process start (that's the initial goal of distinguishing between
> installation and activation directory)
> 3) enforced by our installation process (we currently hardcode
> /etc/bash_completion.d in bash_completion file, instead of relying on
> installation process to set it according to --sysconfdir variable)
> 4) avoid conveniancy symlinks, as the one we're just discussing here
>
> That is supposed to be a 2.0 release objective, after all.
Yes, it would be nice if could tackle this and now incorporate any `helpers'
directory in it. What if we would create an environment variable
`BASHCOMP_PATH' (prefix is going to be `bashcomp_' isn't it?), containing
colon-separated (:) directories. Each of these directories should contain
mandatory directories, being:
- completions (the renamed `contrib')
- helpers
BASHCOMP_PATH typically would contain these directories:
/usr/share/bash-completion
/etc/bash_completion.d/
~/bash_completion.d
but allows for each distribution to vary.
I'm not sure how we would incorporate per-user config settings. Maybe
bash_completion could look in each of the BASHCOMP_PATH directories for a
`bash_completion' or `.bashcomprc' file?
If we would first agree on BASHCOMP_PATH, we could then second decide on how
BASHCOMP_PATH should be set up by an installer.
Thoughts?
> > I'm hesitating to add yet another configuration variable, especially
> > since contrib & helpers are so tied together (we would also need a
> > BASH_COMPLETION_COMPAT_DIR_HELPER, ugh).
> I still don't know what's this variable is for, BTW.
I was thinking if BASH_COMPLETION_DIR/contrib gets a `helpers' dir with a
variable pointing to it, then BASH_COMPLETION_COMPAT_DIR/contrib would need one
as well.
> So, I'm absolutly OK for another symlink as a temporary solution, but
> I'd prefer to achieve our long-time objective as well. And if testing
> has specific issues, I'd prefer them to be solved by test-time only
> solutions/hacks/whatever than permanent setup ones.
Let's add the symlink then until we decide on a final setup. I'm fine with
adjusting the test suite, but I also expect people - just like me - running
bash_completion directly from git HEAD without doing a `make', and I think it
would be better if we can defer `make' substitutions to the install phase so
that the bash_completion source stays simpler.
Greetings,
Freddy Vulto
http://fvue.nl
More information about the Bash-completion-devel
mailing list