[Bash-completion-devel] user-defined dynamic-completions directory(s)
Raphaël
raphael.droz at gmail.com
Fri Feb 13 04:04:43 UTC 2015
Another try on this.
And a patch against bash-completion 2.1-4 as in Jessie.
If the concept seems acceptable I could do that on git master +
the documentation bits.
About XDG_DATA_HOME, I'm still not comfortable about it being the only
choice (even if symlinks are possible).
This comes to the fact that;
- for a command-line based application I feel something between
"strange" and "overkill" (eg: AFAIK bash itself does not treat
~/$XDG_DATA_HOME/.bashrc)
- Whatever is the path of this "bash_completion" directory, it could
very well store completion's configuration (through environment
variable, like COMP_SAMBA_SCAN & co). Thus ~/XDG_CONFIG_HOME could be
valid option too (unless things are split between
~/$XDG_DATA_HOME/bash_completion/completions and
~/$XDG_CONFIG_HOME/bash_completion ...)
One pro of a "standardized" path over a user-defined only path is the
ability of unprivileged 3rd-party tools to install completions
automatically or install them for a specific user (inside
$XDG_DATA_HOME).
This has the side-effect of potentially breaking user's
bash-completion too without the said user even having touched its
configuration himself. The use of a $BASH_COMPLETION_USER_DIR variable
avoids that.
If we ever use a fallback-construct iterating over several user-defined
directories (what the attached patch does), maybe considering only one
unique environment variable as a list of colon-separated paths would
be simpler on the bash-completion side and avoid assumptions about
user's $HOME tree/management.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: load-from-custom-compdir.patch
Type: text/x-diff
Size: 1189 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/bash-completion-devel/attachments/20150213/4401f3bb/attachment.patch>
More information about the Bash-completion-devel
mailing list