[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