[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